- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about ValueAdapter

by StÃ©phane Ducasse

On Aug 27, 2010, at 11:50 PM, Schwab,Wilhelm K wrote: > Stef, > > Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. on base classes we want have better library and we pay attention that they do not impact people. > I will indeed present the adapters as part of a larger whole. focus on one and make it shine people at good at generalization when provided with a nice example. > That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Friday, August 27, 2010 3:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about ValueAdapter > > On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - arrrrggggGGGGGG!!!!! :) >> >> Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. >> >> Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? > > what will survive? > > >> You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. >> >> Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. > > My suggestion is the following. > Show us that this is cool with a nice example. Code is a good value for not native english speakers. > > Stef > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Friday, August 27, 2010 9:07 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] about ValueAdapter >> >> there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. >> >> Stef >> >> On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? >>> >>> As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. >>> >>> What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >>> Sent: Friday, August 27, 2010 4:28 AM >>> To: Pharo-project(a)lists.gforge.inria.fr Development >>> Subject: [Pharo-project] about ValueAdapter >>> >>> Bill >>> >>> I scanned the code. >>> Could you >>> - reformat your code? >>> put space after : >>> align on the first tab >>> - get some more tests? >>> - I could not see the class comments but if there are none then please adde something. >>> - did you check the padded printon methods and others? >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 28, 2010

Re: [Pharo-project] Why is Stack extending from LinkedList?

by StÃ©phane Ducasse

> > In Pharo 1.0 (and Squeak of course). I'm amazed. Our quality process seems weak :) I will check and revert it. Thanks for spotting that. Stef >>> but for some reason it was changed to use inheritance, probably for a "cleaner" system. IMHO the changes should be reverted. >> >> I was not aware that Stack was a subclass of linkedList, it looks again subclassing versus subtyping. And subtyping is better. >> >> Stef >> >>> >>> >>> Levente >>> >>>> >>>> Kind regards, >>>> >>>> Bart >>>> >>>> -- >>>> imagination is more important than knowledge - Albert Einstein >>>> Logic will get you from A to B. Imagination will take you everywhere - >>>> Albert Einstein >>>> Learn from yesterday, live for today, hope for tomorrow. The important thing >>>> is not to stop questioning. - Albert Einstein >>>> The true sign of intelligence is not knowledge but imagination. - Albert >>>> Einstein >>>> However beautiful the strategy, you should occasionally look at the results. >>>> - Sir Winston Churchill >>>> It's not enough that we do our best; sometimes we have to do what's >>>> required. - Sir Winston Churchill >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 28, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Eliot Miranda

On Fri, Aug 27, 2010 at 1:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok if I understand you mean you interpret everything on the copy of the > inputs and you run until you either > get an ok primitives or you stop on not ok one. > Right, /and/ you stop whenever an attempt is made to write to an object not created during the simulation. So one has to trap primitives new, new: & shallowCopy and collect the results along with the copies of the initial arguments. These objects are safe to write to because they were created as one simulates. Anything else is an error. Could be a nice way to stress runSimulated: :) > Interesting to see if this is useful because runSimulated: is probably at least 100 times slower than executing. An alternative would be to have an execution primitive that entered a special mode that did a GC, installed a page fault handler, advanced the allocation pointer to the next page boundary and then write-protected the entire heap. The error handler would unprotect the entire heap and cause a callback that would raise an exception. So one would run until a write into the heap other than to new space. But this alternative requires lots of VM work and is super tricky. Fingers crossed runSimulated: will work :) cheers Eliot > Stef > > > >> > > Ah, and a negative list was I think not used as it is too dangerous wrt. > to completenes. If the positive list is incomplete, you miss > > a hit. If the negative list is incomplete, you woud crash in some nasty > way. > > > > Just look at the lists and how many methods you find that have been > removed years ago... > > > > It's not just methods like #quitPrimitive. In general, with the image > based nature you could end up modifying state of objects > > in the image by accident, and realize it weeks later. > > e.g. this means one would very carefully protect the reflective model, to > not accidentally modify the methodDictionary, for example. > > > > So if someone did try my simulation approach above the only lists needed > would be a positive list of those primitives that were safe to apply to any > object and a positive list of those primitives it would be safe to apply to > the objects allocated during the simulation. > > > > best, > > Eliot > > > > > > Marcus > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 27, 2010

Re: [Pharo-project] about ValueAdapter

by Schwab,Wilhelm K

Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. I will indeed present the adapters as part of a larger whole. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: > Stef, > > Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - arrrrggggGGGGGG!!!!! :) > > Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. > > Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? > You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. > > Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Friday, August 27, 2010 9:07 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about ValueAdapter > > there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. > > Stef > > On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? >> >> As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. >> >> What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >> Sent: Friday, August 27, 2010 4:28 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] about ValueAdapter >> >> Bill >> >> I scanned the code. >> Could you >> - reformat your code? >> put space after : >> align on the first tab >> - get some more tests? >> - I could not see the class comments but if there are none then please adde something. >> - did you check the padded printon methods and others? >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] Why is Stack extending from LinkedList?

by Levente Uzonyi

On Fri, 27 Aug 2010, StÃ©phane Ducasse wrote: > > On Aug 27, 2010, at 6:32 PM, Levente Uzonyi wrote: > >> On Thu, 26 Aug 2010, Bart Gauquie wrote: >> >>> Hi list, >>> >>> is there a specific reason Stack is extending from LinkedList, instead of >>> using a LinkedList internally? >>> To me, it seems that the protocol that LinkedList, SequenceableCollection, >>> ... provides is not the protocol you expect from a Stack? >>> >>> Any thoughts on this? >> >> Originally it used encapsulation, > > when where? In Pharo 1.0 (and Squeak of course). Levente > >> but for some reason it was changed to use inheritance, probably for a "cleaner" system. IMHO the changes should be reverted. > > I was not aware that Stack was a subclass of linkedList, it looks again subclassing versus subtyping. And subtyping is better. > > Stef > >> >> >> Levente >> >>> >>> Kind regards, >>> >>> Bart >>> >>> -- >>> imagination is more important than knowledge - Albert Einstein >>> Logic will get you from A to B. Imagination will take you everywhere - >>> Albert Einstein >>> Learn from yesterday, live for today, hope for tomorrow. The important thing >>> is not to stop questioning. - Albert Einstein >>> The true sign of intelligence is not knowledge but imagination. - Albert >>> Einstein >>> However beautiful the strategy, you should occasionally look at the results. >>> - Sir Winston Churchill >>> It's not enough that we do our best; sometimes we have to do what's >>> required. - Sir Winston Churchill >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 27, 2010

Re: [Pharo-project] [update 1.2] #12116

by StÃ©phane Ducasse

Ah ok! I just took the one in your repo because I was not sure about the other. I will do that tomorrow. Stef On Aug 27, 2010, at 9:36 PM, Sven Van Caekenberghe wrote: > > On 27 Aug 2010, at 21:19, StÃ©phane Ducasse wrote: > >> Strange >> where is the other tests packages? >> in the inbox? > > No, I mean the latest version in Andreas' WebClient repo. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by StÃ©phane Ducasse

Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one. Could be a nice way to stress runSimulated: :) Stef >> > Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss > a hit. If the negative list is incomplete, you woud crash in some nasty way. > > Just look at the lists and how many methods you find that have been removed years ago... > > It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects > in the image by accident, and realize it weeks later. > e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. > > So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. > > best, > Eliot > > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] Why has MethodFinder a fixed list of results?

by Bart Gauquie

Eliot, I think the simulation path is good suggestion. Did a quick test for instance on: ContextPart class>>trace: aBlock on: aStream and modified ^ thisContext sender runSimulated: aBlock contextAtEachStep: [:current | (current receiver == Smalltalk) "added" ifTrue: [self error: 'you cant do this ...']. "added" Sensor anyButtonPressed ifTrue: [^ nil]. and then evaluate: ContextPart trace: ['test' perform: #firstLetter]. => works fine, just prints the trace, ContextPart trace: [Smalltalk printString]. => throws the error. and with a nested piece of code that is also to be illegal : String>>illegalFirstLetter Smalltalk printString. ^self copyFrom: 1 to: 1 ContextPart trace: ['test' perform: #illegalFirstLetter]. => also throws the error :-). Meaning if we keep a negative list of combinations of receiver / or messages, (instead of just the (current receiver == Smalltalk) "added" ifTrue: [self error: 'you cant do this ...']. "added") it is possible to throw errors on nested code that is not be executed ... . Something to try out ... Kind Regards, Bart 2010/8/27 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/8/27 Marcus Denker <marcus.denker(a)inria.fr> > >> >> Smalltalk.true. >> >> takes a while, but it does not try to call #quitPrimitive. Which it would >> if Methodfinder would not be based on a positive list. >> >> >> Ah, and a negative list was I think not used as it is too dangerous wrt. >> to completenes. If the positive list is incomplete, you miss >> a hit. If the negative list is incomplete, you woud crash in some nasty >> way. >> >> Just look at the lists and how many methods you find that have been >> removed years ago... >> >> It's not just methods like #quitPrimitive. In general, with the image >> based nature you could end up modifying state of objects >> in the image by accident, and realize it weeks later. >> e.g. this means one would very carefully protect the reflective model, to >> not accidentally modify the methodDictionary, for example. >> > > So if someone did try my simulation approach above the only lists needed > would be a positive list of those primitives that were safe to apply to any > object and a positive list of those primitives it would be safe to apply to > the objects allocated during the simulation. > > best, > Eliot > > >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill

Aug. 27, 2010

Re: [Pharo-project] could we fix MorphicModel

by Gary Chambers

Indeed, one of the more beautiful bits of Etoys... Regards, Gary Sent from my iPad On 27 Aug 2010, at 10:29, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > gary? > > Do you have surgeon knife? > Because I do not see why slider need to depend on that wonderfully designed code. > > use: cachedSelector orMakeModelSelectorFor: selectorBody in: selectorBlock > | selector | > model ifNil: [^ nil]. > cachedSelector ifNil: > ["Make up selector from slotname if any" > selector := (slotName ifNil: [selectorBody] > ifNotNil: [slotName , selectorBody]) asSymbol. > (model class canUnderstand: selector) ifFalse: > [(self confirm: 'Shall I compile a null response for' > , Character cr asString > , model class name , '>>' , selector) > ifFalse: [self halt]. > model class compile: (String streamContents: > [:s | selector keywords doWithIndex: > [:k :i | s nextPutAll: k , ' arg' , i printString]. > s cr; nextPutAll: '"Automatically generated null response."'. > s cr; nextPutAll: '"Add code below for appropriate behavior..."'.]) > classified: 'input events' > notifying: nil]] > ifNotNil: > [selector := cachedSelector]. > ^ selectorBlock value: selector > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 27, 2010

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.

by Sven Van Caekenberghe

It works now: I tried closing all open windows in the image and now it runs headless. I thought that wasn't necessary with other VMs but maybe I always did so without thinking about it. Thanks for answering, Eliot. Sven On 27 Aug 2010, at 20:46, Eliot Miranda wrote: > On Fri, Aug 27, 2010 at 1:59 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 26 Aug 2010, at 21:44, Sven Van Caekenberghe wrote: > > > I hope the linux VM is equally fast. > > Is the COG VM capable of running headless on Linux ? > > We routinely run it headless on linux using -vm-display-null. > > sven@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -version > 3.9-7 #2 Wed Aug 18 19:45:40 GMT 2010 gcc 4.1.2 > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.26] > Linux cern 2.6.18-194.8.1.el5PAE #1 SMP Fri Jul 2 10:18:13 CEST 2010 i686 i686 i386 GNU/Linux > plugin path: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/ [default: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/] > > sven@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -vm-display-null -vm-sound-null seaside3.lr.cog.image > > This doesn't seem to work, no errors to be seen anywhere. Can I enable some debugging output ? > > Try -sendtrace, e.g. > ./coglinux/bin/squeak -vm-display-null -vm-sound-null -sendtrace seaside3.lr.cog.image > > This same image runs perfectly well with a display, as in > > sven@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak seaside3.lr.cog.image > > What does your image do? Does it depend on any additional plugins or shared objects? Are these also present in your Cog installation? > > HTH > Eliot > > Thx, > > Sven

Aug. 27, 2010