February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] detecting if method has an prim error code

by Igor Stasenko

Is there a simple way to detect that given method using: myMethod <primitive: #primFoo module: #moduleBar error: errorCode> but not: myMethod <primitive: #primFoo module: #moduleBar> ? should i use a method's pragmas to see if it has #primitive:module:error: pragma? And if this check is ok, do i remember correctly, that temp which is used for storing an error is first temp in context, i.e.: err := context tempAt: 1 ? (ok i checked, it is actually always last temp), no matter if i declare temps before pragma or not. i.e. the order is same for: myMethod | a b c | <primitive: #primFoo module: #moduleBar error: errorCode> and myMethod <primitive: #primFoo module: #moduleBar error: errorCode> | a b c | -- Best regards, Igor Stasenko.

Feb. 10, 2012

[Pharo-project] please ignore - just a test

by Ben Coman

I am testing a hypothesis about the format of my posts that got screwed up. Please excuse the noise. This is a test Over several lines With each new line Starting with a capital letter And no line ending with a colon. This is a test Over several lines : With each new line Starting with a capital letter : But two of the lines ending with a colon.

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Yanni Chiu

On 10/02/12 10:24 AM, Martin Dias wrote: > Maybe is too much overhead, but it is also possible to serialize an > object that represents the metadata as a prefix: > > FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | > aStream binary. > metadata := Dictionary with: #meta -> 5. > content := 'stuff'. > FLSerializer newDefault > serialize: metadata on: aStream; > serialize: content on: aStream ]. > > FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | > | aMaterializer | > aStream binary. > aMaterializer := FLMaterializer newDefault. > metadata := (aMaterializer materializeFrom: aStream) root. > content := (aMaterializer materializeFrom: aStream) root ]. I like this solution best, since it doesn't change the Fuel "file format". I added some helper methods to my code base to make this usage scenario more obvious: FLMaterializer>>nextMaterializedRootFrom: sourceStream ^ (self materializeFrom: sourceStream) root FLMaterializer>>allMaterializedRootsFrom: sourceStream | contents | contents := OrderedCollection new. [ sourceStream atEnd ] whileFalse: [ contents add: (self nextMaterializedRootFrom: sourceStream) ]. ^ contents Sample usage: FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | | serializer | aStream binary. serializer := FLSerializer newDefault. (1 to: 5) do: [ :each | serializer serialize: (Dictionary with: each -> (each * each)) on: aStream ]. ]. FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | | aMaterializer | aStream binary. aMaterializer := FLMaterializer newDefault. aMaterializer allMaterializedRootsFrom: aStream ]. FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | | aMaterializer | aStream binary. aMaterializer := FLMaterializer newDefault. aMaterializer nextMaterializedRootFrom: aStream. aMaterializer nextMaterializedRootFrom: aStream. ].

Feb. 10, 2012

[Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins

by Ben Coman

While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image. Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. cheers, -ben Ben Coman wrote: > Schwab,Wilhelm K wrote: >> One snag: I'm still getting strangely broken images (won't open >> process browser or debugger) after trying to download some things. I >> have mirrored squeak source, BUT, some things (SIXX, ODBC) don't >> appear to have working configs, so I'm trying to grab the latest >> packages, and *that* might not be mirrored. I might need to specify >> the mirror server in my code to make them work. >> >> Still, I don't get how simply asking MC to download something will >> permanently mar the image w/o my doing an explicit save. Does MC >> snapshot before/during an attempted load? It seems very misguided >> that an innocent attempt to load something can hobble an image?? >> >> One other crazy possibility: is killing a vm from the (Ubunutu) >> system monitor somehow not sufficient to clear what is running? Dumb >> question? Maybe, but I'm stumped. Any ideas? >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of blake >> [dsblakewatson(a)gmail.com] >> Sent: Thursday, February 09, 2012 2:58 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 1.4 - better from Jenkins >> >> I just downloaded the latest CogWin and Pharo 1.4 image and I got >> "WARNING: Manufactured file handle detected!" at the bottom, and popup >> full of startup errors. >> > A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I > had the same warning, with a debugger showing "Error: Got startup errors" > in method SmalltalkImage snapshot:andQuit: " at line: > startupErrors isEmpty > ifFalse: [ self error: 'Got startup errors ' ]. > where startupErrors = an OrderedCollection(ShouldBeImplemented: > #preferencesFolder should have been implemented in DosFileDirectory > class) > > So I thought I may as well try implementing > DosFileDirectory>>preferencesFolder - which I've left as a comment on > ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> > A nice side effect of this was that all the "WARNING: Manufactured > file handle detected!" went away. Reverting this change reintroduces > the warnings. > > cheers, -ben > >

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Ben Coman

Schwab,Wilhelm K wrote: > One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work. > > Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image?? > > One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas? > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of blake [dsblakewatson(a)gmail.com] > Sent: Thursday, February 09, 2012 2:58 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 1.4 - better from Jenkins > > I just downloaded the latest CogWin and Pharo 1.4 image and I got > "WARNING: Manufactured file handle detected!" at the bottom, and popup > full of startup errors. > A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class) So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings. cheers, -ben

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Igor Stasenko

On 10 February 2012 16:24, Martin Dias <tinchodias(a)gmail.com> wrote: > Maybe is too much overhead, but it is also possible to serialize an object > that represents the metadata as a prefix: > > FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | > aStream binary. > metadata := Dictionary with: #meta -> 5. > content := 'stuff'. > FLSerializer newDefault > serialize: metadata on: aStream; > serialize: content on: aStream ]. > > FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | > | aMaterializer | > aStream binary. > aMaterializer := FLMaterializer newDefault. > metadata := (aMaterializer materializeFrom: aStream) root. > content := (aMaterializer materializeFrom: aStream) root ]. > > Martin which eventually could be turned into simple: MyStuff>>serializeOn: stream serializer := FLSerializer newDefault. serializer serialize: {myStuff. myMetaStuff. myMetaMetaStuff } on: stream ]. so, you don't even need to care about stream contents :) -- Best regards, Igor Stasenko.

Feb. 10, 2012

[Pharo-project] Need help with OpenGL visual creation on linux

by Javier PimÃ¡s

I'm trying to create an OpenGL context on linux but glxChooseVisual fails. Maybe there's someone there experienced with this that can help. The code I'm trying is: display := NBXLibDisplay open. window := display defaultRootWindow. visualInfo := NBXLibVisualInfo fromPointer: (gl chooseVisual: display screen: display defaultScreen attributes: {GLX_RGBA. GLX_DEPTH_SIZE. 24. GLX_DOUBLEBUFFER. 0} asWordArray). ... but chooseVisual returns a null pointer. I even tried putting an array with only 0 on attributes but didn't work either (and these attributes should be supported). Any idea of what could be wrong? The code is available to test in squeaksource, you need nativeboost+NBXLib to try Cheers, Javier -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 10, 2012

[Pharo-project] [update 1.4] #14327

by Marcus Denker

14327 ----- Issue 5273: Dragging files on the window (e.g. .cs) not working http://code.google.com/p/pharo/issues/detail?id=5273 Issue 5271: Bug in checkbox http://code.google.com/p/pharo/issues/detail?id=5271 -- Marcus Denker -- http://marcusdenker.de

Feb. 10, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Martin Dias

Maybe is too much overhead, but it is also possible to serialize an object that represents the metadata as a prefix: FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | aStream binary. metadata := Dictionary with: #meta -> 5. content := 'stuff'. FLSerializer newDefault serialize: metadata on: aStream; serialize: content on: aStream ]. FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | | aMaterializer | aStream binary. aMaterializer := FLMaterializer newDefault. metadata := (aMaterializer materializeFrom: aStream) root. content := (aMaterializer materializeFrom: aStream) root ]. Martin On Fri, Feb 10, 2012 at 8:25 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 February 2012 10:19, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > >>> All you need to do is to send it a stream. If the > >>> stream is already at a certain position, it doesn't matter it will > start > >>> from that position. Say you have stream where you write something first > >>> and > >>> then you give it to Fuel to serialize. The stream would be at some > >>> position > >>> different than zero. Say, at position 10. Fuel will start serializing > for > >>> there. Say we have written 40 bytes. Then, at materialization, when > you > >>> give it the stream, you have to be sure to give the stream starting at > >>> the > >>> position 10. > >> > >> However if you consider Fuel "the standard file format" - this would > >> appear to be broken by people using random offsets. > > > > > > > > yes, sure. But I think its ok to fail from the serializer point of view. > It > > is YOUR responsability to provide the correct streams. > > > > > >>> > >>> Fuel will load EXACTLY 40 bytes and will stop. The stream can > >>> continue....fuel doesn't care and it will store exactly when it > finishes > >>> reading his own bytes. > >>> > >>> BTW, this is how some databases work. The save several serialized > objects > >>> in the same stream... > >>> > >> > >> To reach for the moon... Perhaps Fuel "the standard file format" holding > >> multiple streams might be formalized by tagging different each stream > with a > >> 'name' and/or a 'type' and/or 'deserializerMethod'. The first two of > these > >> might be '#fuel -> #fuelDeserializer' and '#meta->#textDeserializer'. > > > > > > I don't understand. Fuel holding multiple streams ? why? for what? > > > >> > >> The the default Fuel system can then automatically ignore 3rd-party > data. > > > > > > I want to make my point clear: Martin proposed an example that solves > Yanni > > problem. If you serialize with a stream with a certain position, then you > > have to materialize it with its correct position. Dot. It is perfect that > > the materializer is broken if you do not give him the correct stream. > > Now, I DO agree that there could be another solution rather than adhoc, > > supported by fuel so that BY DEFAULT some data could be set and ignored > at > > the same time...so that there is no manipulation of the srteam by the > user. > > > > > no i think your approach is fine. you store what you need, and don't > care/intervene with other parts of stream, > so if user wants to add some stuff before materialized data, he free to do > so. > > > -- > Best regards, > Igor Stasenko. > >

Feb. 10, 2012

[Pharo-project] about name hashWithInitialHash: 0.

by StÃ©phane Ducasse

Hi levente we are performing a study with veronica and we looked at Monticello-ul.331 in squeak trunk you mentioned that name hashWithInitialHash: 0. is faster than String stringHash: name initialHash: 0. and I was wondering if this is true and why? String hashWithInitialHash: initialHash ^ self class stringHash: self initialHash: initialHash hash | hash | hash := name hashWithInitialHash: 0. hash := superclassName hashWithInitialHash: hash. hash := self traitCompositionString hashWithInitialHash: hash. hash := self classTraitComposition asString hashWithInitialHash: hash. hash := (category ifNil: ['']) hashWithInitialHash: hash. hash := type hashWithInitialHash: hash. variables do: [ :v | hash := v name hashWithInitialHash: hash ]. ^hash => hash | hash | hash := String stringHash: name initialHash: 0. hash := String stringHash: superclassName initialHash: hash. hash := String stringHash: self traitCompositionString initialHash: hash. hash := String stringHash: self classTraitComposition asString initialHash: hash. hash := String stringHash: (category ifNil: ['']) initialHash: hash. hash := String stringHash: type initialHash: hash. variables do: [ :v | hash := String stringHash: v name initialHash: hash. ]. ^ hash Thanks in advance Stef and Veronica

Feb. 10, 2012