Hi Stefan!
On Wed, Feb 12, 2014 at 12:35 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote:
> Hi:
>
> Below you see the result of today, the simulator for the StackInterpreter
> running in a Pharo 3 image.
>
Fab! This is great.
Over the last years, people have been tinkering with the simulator from
> time to time, but I have the feeling everyone gave up before the thing was
> fully functioning, and not even the trivial things have found their way
> back into the VM code base.
>
How can anyone do anything significant with the VM without getting the
simulator to work? [ ;-) ] You know about the first attempt at making a
64-bit VM for HP don't you? A nightmare tale :-).
> I am aware that Phil was busy with it recently, but I think there was also
> someone else posting notes here.
>
> Would be great if those people could send me their change sets so that I
> can try getting everything working again.
>
> As you can see in the screenshot, the simulator loads up properly, and
> executes the first 10,000,000 bytecodes.
> Which is enough to make it notice that a primitive fails, and to pop up
> the error dialog.
> However, it is a Pharo 1.2 image. Later images trigger some bug, I haven't
> identified yet. They execute code, but don't manage to bring up the display.
>
>
> Thanks to having a unified code repository, everything I got so far (minus
> a few small changes) is here:
> https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot
>
Hmm. What's the easiest way to map this to a Monticello mcz so I can
integrate your changes back into my packages?
> More to come soon.
> Best regards
> Stefan
>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>
--
best,
Eliot
Hi:
I am slowly getting acquainted with CMake and the CMakeVMMaker infrastructure.
In order to build the BochsIA32Plugin for the Cog simulator, I need to pass a number of build flags.
Would be great if someone could tell me how to realize the following things:
1. remove -std=gnu99 for only this plugin
BochsIA32Plugin is written in C++ and Clang doesn’t support the `-std=gnu99` switch in that case.
2. add header include paths
The plugin needs the following two includes to access Bochs’ headers:
-I${root}/processors/IA32/bochs/ -I${root}/processors/IA32/bochs/instrument/stubs/
3. the final binary needs the following linker flags
-lcpu -ldisasm -lfpu -L${root}/processors/IA32/macbochs/disasm/
-L${root}/processors/IA32/macbochs/cpu/ -L${root}/processors/IA32/macbochs/fpu/
In addition to that I would also need to add a script to build the bochs library before linking the binary.
Any hints how to do that are very appreciate.
Thanks
Stefan
--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/
Hi Ronie,
On Thu, Feb 13, 2014 at 11:47 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote:
> I am proposing the following as a student:
>
> Project idea
>
> Name: Unified Foreign Function Interface
> Skill level: Advanced
> Possible Mentors: Igor Stasenko / Esteban Lorenzano
> Name of the Student: Ronie Salgado
>
> Description:
>
> Because NativeBoost has problems with portability and cannot be used
> anywhere(iOS), one proposal is making a modular unified foreign function
> interface. This UFFI should support multiples backends, a portable function
> calls specification, portable easy to use callbacks support, and portable
> foreign resources management.
>
> Full Description Document:
> http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf
>
This is interesting but I take issue with a couple of things. First of all
"The old Squeak FFI has problems with portability, callbacks and speed."
I disagree that there are problems with callbacks. In fact, IIRC the only
callback facility we have is that which I implemented which is used both by
Alien and FFI and works well enough that the Newspeak system used it to
implement a native GUI on windows where callbacks are used to receive
Windows events. That counts as working in my book. Also, the architecture
I implemented is portable to other ABIs than x86.
But my major objection is to this:
"One interesting idea is to make a backend that uses LLVM compiler
infrastruc- ture, because it is designed for compiling optimized C function
and it already has multiples JIT backends. This small project is not to
make a full Pharo VM JIT based in LLVM, because LLVM is not designed for
that and it would require a lot of patching of LLVM."
IMO that's a very poor choice. LLVM is large, having a footprint of about
a couple of megabytes. The Cog JIT is in contrast about 330k at its
largest (Newspeak, support for two instruction sets, plus primitives, plus
GC interface, etc, etc). If we as a community put effort into extending
this we'll have a smaller footprint, a better JIT, and less dependencies.
There's insignificant opportunity for using LLVM's optimizer when
engineering call-outs and call-backs; they're too simple. So there's
nothing to be gained other than bloat and dependency. And not putting
effort into our own infrastructure is IMO a very bad idea.
Note the synergy with Clément and my work on speculative inlining which
will extend the Cog JIT.
2014-02-13 12:21 GMT-03:00 tesonep(a)gmail.com <tesonep(a)gmail.com>:
>
> Project idea
>>
>> Description: Enhance refactorings with type information
>> Skill level: Advance
>> Possible Mentors: Guillermo Polito / Esteban Lorenzano / Santiago
>> Bragagnolo
>> Name of the Student: Pablo Tesone
>> Keywords: tools, refactoring, code completion, type inference.
>>
>> Description:
>>
>> During the development of a program in any programming language, the IDE
>> has a very important role. It will never replace the knowledge of the
>> programmer but it can make his life easier.
>> As Smalltalk doesn't have explicit type information, the IDE can not
>> perform the same mechanisms that are present in IDE like Eclipse or
>> Intellij IDEA. These mechanisms can be very useful.
>> The idea of this project is to add type inference mechanisms to try to
>> provide more information to the refactoring and code completion tools.
>> It is important to say that the idea is not to check types or correct the
>> program, but to allow the programmer to have more information.
>>
>>
>>
>> On Thu, Feb 13, 2014 at 12:06 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote:
>>
>>> [Anne Etien could not post this msg on the mentors list I m forwarding
>>> it on her behalf].
>>>
>>> Title: FAST JavaScript model
>>>
>>> Level: advanced
>>>
>>> Possible mentor: Anne Etien
>>>
>>> Possible second mentor: Nicolas Anquetil or Yuriy Tymchuk
>>>
>>> Description:
>>> For in depth source code analysis a support of abstract syntax trees is
>>> required. FAST is an abstract syntax tree extension for FAMIX meta-model
>>> that is used by Moose technology. The goal of this project is to create
>>> a JavaScript version of FAST.
>>>
>>> Technical Details:
>>> As programming languages are different, their AST representations are
>>> different too. FAST model aims for creation of as generic as possible
>>> core that can be extended for different languages. Also the structure of
>>> a model allows creation of generic algorithms like symbol resolution,
>>> metrics calculation and rule checking that will work for any language.
>>> Prototypes of FAST for Smalltalk and Java are already implemented.
>>> During the project a student will implement the JavaScript model. More
>>> detailed information about FAST is provided in the Moose day
>>> presentation: http://youtu.be/dRr3WHOD3x4
>>>
>>> Benefits to the Student:
>>> The student will gain a deep understanding of a JavaScript syntax and
>>> abstract syntax tree model. He will also learn about PetitParser
>>> framework, and gain knowledge about software modeling and analysis.
>>>
>>> Benefits to the Community:
>>> Community will get a FAST model for JavaScript that can be used for
>>> software assessment with Moose. Also this model can be used later in PhD
>>> projects such as automation of source code translation. With this third
>>> model, the community will have raw material to real think and improve
>>> generic algorithms based on AST.
>>>
>>>
>>> On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou <damien.cassou(a)gmail.com
>>> > wrote:
>>>
>>>> Hi fellow Pharo hackers,
>>>>
>>>> ESUG, the European Smalltalk User Group, is applying for this
>>>> year's Google Summer of Code. As you probably know, the Summer
>>>> of Code provides the opportunity to fund students to work during
>>>> the summer on Pharo. Please reply to this
>>>> email (be sure to use "Reply to all") if you have ideas you
>>>> would like to propose.
>>>>
>>>> Please include a summary of the project and links to web pages
>>>> that can help prospective students to write their application.
>>>> Please also include the following information:
>>>>
>>>> - if applicable, other dialects that you would be willing to
>>>> mentor this project for
>>>>
>>>> - the skill level
>>>>
>>>> - name of the mentor(s), email addresses, and possibly any IRC
>>>> network/channel/nickname where they can be found.
>>>>
>>>> Thanks for contributing to ESUG's Summer of Code application!
>>>>
>>>> --
>>>> Damien Cassou
>>>> http://damiencassou.seasidehosting.st
>>>>
>>>> "Success is the ability to go from one failure to another without
>>>> losing enthusiasm."
>>>> Winston Churchill
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Smalltalk GSoC mentors" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Smalltalk GSoC mentors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Pablo Tesone.
>> tesonep(a)gmail.com
>>
>
>
--
best,
Eliot
(followups to vm-dev, please)
Hi Phil--
> ...having a clean interpreter and a basic image (Maybe
> PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple
> image to simulate - the whole image isn't really needed).
Yeah, the simulator is crucial to the Spoon[1] work, and I've kept
it working for its development memories at all times. None of those
memories have GUIs in them, but I am simulating things that were never
simulated before, like live network access (so remote messaging between
a simulated memory and a normal one works).
thanks,
-C
[1] http://netjam.org/spoon
--
Craig Latta
www.netjam.org/resume
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)
cc'ing vm-dev cuz /this is a vm-dev issue/.
On Wed, Feb 12, 2014 at 4:40 AM, Danil Osipchuk <danil.osipchuk(a)gmail.com>wrote:
> Hello all
>
> I'm currently playing with NativeBoost (a great thing to have) and pharo
> consistently crashes after running for a while. My impression is that
> crashes happen during GCs as if something moves under the installed
> callback. This may be also related to the libpcap itself, but how can I
> know for sure. I've tried everything newest (vm+image+libpcap) and I also
> migrated into a much more rigid scheme of storing and passing callback. Now
> I've run of ideas where to look further.
>
> So, it is like this. NBPCapHandlerCallback is a procedure which is called
> by libpcap for every packet it has in its internal buffer after the
> application calls pcap_dispatch(). pcap_dispatch receives the callback as a
> parameter. I have to repeatedly call pcap_dispatch in so called
> nonblocking mode (and pass the callback each time) every 5 milliseconds to
> collect packets - we are single threaded. This amounts to awful whole 200
> callback installations per second, may be libpcap was not well tested in
> this scenario (I suppose pcap_loop runs in separated thread in wireshark
> and callback installation happens several times per session at most) -
> hence my doubts. But also - could it be something with NB?
>
> Any hints how to proceed with it are greatly appreciated. This is amazing
> how one can quickly assemble something that emulates thousands of
> dhcp-clients (this is what the app does) with current Pharo. But the thing
> dies off after 10-15 minutes.
>
There is a leak checker in the VM that you can use. Use -leakcheck 3 to
run the leak checker before each full GC (1) and incremental GC (2, 1 + 2 =
3). Use -leakcheck 7 to run it before each become as well. This should at
least print an error before the crash. If you then use gdb to stop in the
warning function you can use facilities such as printOop to find out which
object is crapping out.
HTH
and please bring issues like this up on vm-dev.
>
>
> best wishes,
> Danil
>
> http://www.tcpdump.org/manpages/pcap_loop.3pcap.html
>
> =========
> Generic failure
> NBNativeCodeGen class>>signalError:
> NBNativeCodeGen class>>handleFailureIn:nativeCode:
> NBNativeCodeGen class>>methodAssembly:
>
> LargePositiveInteger(NBFFICallback)>>primLeave:stackPtr:contextOop:returnValue:primitiveMethod:
> NBPCapHandlerCallback(NBFFICallback)>>pvtEnter:stackPointer:primitiveMethod:
> in Block:
> Segmentation fault Wed Feb 12 16:17:25 2014
>
>
> pharo VM version: 3.9-7 #1 Fri Feb 7 16:55:52 CET 2014 gcc 4.6.3
> [Production ITHB VM]
> Built from: NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 Feb 7 2014
> With: NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 Feb 7 2014
> Revision: https://github.com/pharo-project/pharo-vm.git Commit:
> ef5832e6f70e5b24e8b9b1f4b8509a62b6c88040 Date: 2014-01-26 15:34:28 +0100
> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14797
> Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep
> 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
> plugin path: /home/Pharo/ [default: /home/Pharo/]
>
>
> C stack backtrace:
> ./pharo[0x809bc4c]
> ./pharo[0x809bf66]
> linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xb76e640c]
> ./pharo(incrementalGC+0x18a)[0x80859da]
> ./pharo[0x808655a]
> ./pharo[0x808cbb7]
> ./pharo[0x808ccba]
> ./pharo(ceStackOverflow+0x59)[0x808f5f9]
> [0x770f5260]
> [0x771017e0]
> [0x770fb11e]
> [0x770fa939]
> [0x770f9813]
> [0x770f5700]
> [0x770f55c0]
>
>
> Smalltalk stack dump:
> 0xbf8b6144 M BlockClosure>ensure: 0x7c429d44: a(n) BlockClosure
> 0xbf8b6164 M Semaphore>critical: 0x772901d8: a(n) Semaphore
> 0xbf8b6180 M SmallInteger(Integer)>atRandom 0x13=9
> 0xbf8b61a8 M NLDHCPClientInit>enter 0x7c3be76c: a(n) NLDHCPClientInit
> 0xbf8b61c0 M [] in NLDHCPHost>changeStateTo: 0x793e816c: a(n) NLDHCPHost
> 0xbf8b61e0 I [] in BlockClosure>newProcess 0x7c3be828: a(n) BlockClosure
>
> Most recent primitives
> at:put:
> at:put:
> at:put:
> at:put:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> species
> species
> at:put:
> at:put:
> class
> class
> replaceFrom:to:with:startingAt:
> species
> species
> at:put:
> at:put:
> class
> class
> replaceFrom:to:with:startingAt:
> at:put:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> class
> class
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> basicNew:
> atAllPut:
> class
> class
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> at:put:
> at:put:
> class
> at:put:
> at:put:
> at:put:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> basicNew:
> at:put:
> at:put:
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> new
> at:put:
> at:put:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> basicNew
> objectAt:
> basicNew:
> stackp:
> basicNew
> primitiveResume
> basicNew
> basicNew
> new:
> basicNew
> new:
> objectAt:
> basicNew:
> stackp:
> basicNew
> primitiveResume
> findNextUnwindContextUpTo:
> terminateTo:
> suspend
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> species
> class
> class
> basicNew
> shallowCopy
> shallowCopy
> basicNew:
> basicNew
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> basicNew:
> basicNew
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> class
> class
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> wait
> truncated
> truncated
> signal
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> new
> at:put:
> at:put:
> class
> at:put:
> at:put:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> class
> species
> hashBytes:startingWith:
> species
> species
> class
> class
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> class
> stringHash:initialHash:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> basicNew:
> basicNew
> class
> class
> replaceFrom:to:with:startingAt:
> class
> class
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> class
> class
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> pcapSendPacket:size:
> findNextUnwindContextUpTo:
> terminateTo:
> suspend
> basicNew
> basicNew
> wait
> **IncrementalGC**
>
> stack page bytes 4096 available headroom 3300 minimum unused headroom 3480
>
> (Segmentation fault)
>
>
--
best,
Eliot
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/..VMMaker.oscog-eem.617.mcz
==================== Summary ====================
Name: ..VMMaker.oscog-eem.617
Author: eem
Time: 13 February 2014, 9:38:02.186 am
UUID: 522aeee6-194d-4777-a4a5-19e312108e86
Ancestors: ..VMMaker.oscog-eem.616
Use Smalltalk vm getSystemAttribute: instead of plain old
Smalltalk getSystemAttribute:
=============== Diff against ..VMMaker.oscog-eem.616 ===============
Item was changed:
----- Method: CogVMSimulator>>primitiveGetAttribute (in category 'other primitives') -----
primitiveGetAttribute
"Fetch the system attribute with the given integer ID. The result is a string, which will be empty if the attribute is not defined."
| index s attribute |
index := self stackIntegerValue: 0.
self successful ifTrue: [
+ attribute := systemAttributes at: index ifAbsent: [Smalltalk vm getSystemAttribute: index].
- attribute := systemAttributes at: index ifAbsent: [Smalltalk getSystemAttribute: index].
attribute ifNil: [ ^self primitiveFail ].
s := objectMemory instantiateClass: (objectMemory splObj: ClassByteString) indexableSize: attribute size.
1 to: attribute size do: [ :i |
objectMemory storeByte: i-1 ofObject: s withValue: (attribute at: i) asciiValue].
+ self pop: 2 "rcvr, attr" thenPush: s]!
- self pop: 2. "rcvr, attr"
- self push: s]!
Item was changed:
----- Method: InterpreterSimulator>>primitiveGetAttribute (in category 'other primitives') -----
primitiveGetAttribute
"Fetch the system attribute with the given integer ID. The result is a string, which will be empty if the attribute is not defined."
| attr s attribute |
attr := self stackIntegerValue: 0.
successFlag ifTrue: [
+ attribute := Smalltalk vm getSystemAttribute: attr.
- attribute := Smalltalk getSystemAttribute: attr.
attribute ifNil: [ ^self primitiveFail ].
s := self instantiateClass: (self splObj: ClassByteString) indexableSize: attribute size.
1 to: attribute size do: [ :i |
self storeByte: i-1 ofObject: s withValue: (attribute at: i) asciiValue].
+ self pop: 2 "rcvr, attr" thenPush: s].
- self pop: 2. "rcvr, attr"
- self push: s].
!
Item was changed:
----- Method: NewspeakInterpreterSimulator>>primitiveGetAttribute (in category 'other primitives') -----
primitiveGetAttribute
"Fetch the system attribute with the given integer ID. The result is a string, which will be empty if the attribute is not defined."
| attr s attribute |
attr := self stackIntegerValue: 0.
self successful ifTrue: [
+ attribute := Smalltalk vm getSystemAttribute: attr.
- attribute := Smalltalk getSystemAttribute: attr.
attribute ifNil: [ ^self primitiveFail ].
s := self instantiateClass: (self splObj: ClassByteString) indexableSize: attribute size.
1 to: attribute size do: [ :i |
self storeByte: i-1 ofObject: s withValue: (attribute at: i) asciiValue].
+ self pop: 2 "rcvr, attr" thenPush: s].
- self pop: 2. "rcvr, attr"
- self push: s].
!
Item was changed:
----- Method: StackInterpreterSimulator>>primitiveGetAttribute (in category 'other primitives') -----
primitiveGetAttribute
"Fetch the system attribute with the given integer ID. The result is a string, which will be empty if the attribute is not defined."
| index s attribute |
index := self stackIntegerValue: 0.
self successful ifTrue: [
+ attribute := systemAttributes at: index ifAbsent: [Smalltalk vm getSystemAttribute: index].
- attribute := systemAttributes at: index ifAbsent: [Smalltalk getSystemAttribute: index].
attribute ifNil: [ ^self primitiveFail ].
s := objectMemory instantiateClass: (objectMemory splObj: ClassByteString) indexableSize: attribute size.
1 to: attribute size do: [ :i |
objectMemory storeByte: i-1 ofObject: s withValue: (attribute at: i) asciiValue].
+ self pop: 2 "rcvr, attr" thenPush: s]!
- self pop: 2. "rcvr, attr"
- self push: s]!
On Thu, Feb 13, 2014 at 6:19 AM, <btc(a)openinworld.com> wrote:
> phil(a)highoctane.be wrote:
>
>> Ron,
>>
>> Sure but at this time, not being able to run the simulator in a full
>> Pharo environment is a severe issue.
>>
>> The key advantage is that the Smalltalk VM is written in itself.
>>
>> Now, what do I experience is that it is hard to embark on VM work.
>>
>> Why? Even if the PharoVMBuilders help in generating and compiling the VM
>> for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc)
>> this is only one part of the puzzle.
>>
>> The next step, is to understand how things do work for real, the
>> interpret() C loop isn't gonna help me one bit, I need to be able to
>> simulate this one in a Simulator. And I want to do that on the Pharo
>> platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.
>>
>> I am not in the league of the VM maintainers obviously.
>>
>> But Clement provided me with Eliot's Cog Simulation image, which works
>> for his own work. But only his own. We do not have something like a
>> Configuration to get the same thing. And that's a very acute pain. There
>> are only so many hours in a day, true. So, in order to bring in more
>> people/resources for the VM work, the barrier to entry should be moved a
>> tad down.
>>
>> We tried to have the StackSimulator working for a while (Stephan I'll
>> definitely get your version, thanks for it). This is also because
>> InterpreterSimulator doesn't work anymore and we have to use the
>> StackInterpreter instead (which is complicated already vs pure interpreter).
>>
>> All of this rant to say that having a clean interpreter and a basic image
>> (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very
>> simple image to simulate - the whole image isn't really needed. Hopefully
>> Oz will also move us forward on that front).
>>
>> A real Pharo image is overkill for this as a ton of plugins get involved
>> etc.
>>
>> The core system should be the same for Pharo/Squeak/... :
>>
>> VMMaker-MemoryManager
>> VMMaker-Interpreter
>> VMMaker-InterpreterSimulation
>> VMMaker-MemoryManagerSimulation
>>
>> and of course the Slang things (VMMaker-Support and VMMaker-Translation
>> to C).
>>
>> What I'd love to end up with is an embeddable VM that we could hook into
>> other environments, languages etc (a bit like TCL for example). This
>> requires work on how the VM core runs. And to explore this, simulation is
>> needed.
>>
>> Sorry for the long post. I wish I was a millionaire to pour in some cash
>> into the project to speed some areas up. Working on it :-) Maybe should we
>> work in that direction for funding. http://www.gv.com/ where are you?
>>
>> Phil
>>
>> Getting the simulator working in Pharo could be a GSoC project? or is it
> too advanced?
>
If you guys would read and contribute to vm-dev you'd already know that
someone with no VM experience (tty) just implemented event processing for
the simulator window. The simulator only supported the old polling event
architecture. So no it's not too advanced. But more importantly why
aren't you all discussing vm stuff on the vm forum?
> cheers -ben
>
--
best,
Eliot