- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About (nil@nil)

by Mariano Martinez Peck

>From can I can see with me newbie search in the VM, it is not used. splObj: 33 ObjectMemory class >> initializeSpecialObjectIndices TheInterruptSemaphore := 30. SelectorCannotInterpret := 34. it jumps from 30 to 34. I search places doing "splObj: 33" but I didn't find anything. Maybe the VM guys can confirm or reject this. Cheers Mariano On Thu, Apr 21, 2011 at 6:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > of course it is there > > newArray at: 34 put: Point new. > > now could not we have a well initialized point? > What is the purpose of this one? > > Stef > > > On Apr 21, 2011, at 6:39 PM, StÃ©phane Ducasse wrote: > > > with manuel oriol we started to play with the idea of a randomTester in > Pharo. It poses a lot of questions. > > > > Now doing the first experiments, I found an instance of point (nil@nil) > (besides reciprocal broken on Point (0@0) and > > > > (Point allInstances select: [:each | each x isNil]) first pointersTo > > > > points me to recreateSpecialObjectsArray > > > > I looked into the literals and others and I could not find. > > > > Each time I execute > > Smalltalk recreateSpecialObjectsArray > > > > I get a new nil@nil objects.... but forcing a GC garbage them. > > But I still have this nil@nil object around. > > > > Does anybody have an idea from where nil@nil could come from? > > > > Stef > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 21, 2011

Re: [Pharo-project] About (nil@nil)

by StÃ©phane Ducasse

of course it is there newArray at: 34 put: Point new. now could not we have a well initialized point? What is the purpose of this one? Stef On Apr 21, 2011, at 6:39 PM, StÃ©phane Ducasse wrote: > with manuel oriol we started to play with the idea of a randomTester in Pharo. It poses a lot of questions. > > Now doing the first experiments, I found an instance of point (nil@nil) (besides reciprocal broken on Point (0@0) and > > (Point allInstances select: [:each | each x isNil]) first pointersTo > > points me to recreateSpecialObjectsArray > > I looked into the literals and others and I could not find. > > Each time I execute > Smalltalk recreateSpecialObjectsArray > > I get a new nil@nil objects.... but forcing a GC garbage them. > But I still have this nil@nil object around. > > Does anybody have an idea from where nil@nil could come from? > > Stef > > > >

April 21, 2011

[Pharo-project] About (nil@nil)

by StÃ©phane Ducasse

with manuel oriol we started to play with the idea of a randomTester in Pharo. It poses a lot of questions. Now doing the first experiments, I found an instance of point (nil@nil) (besides reciprocal broken on Point (0@0) and (Point allInstances select: [:each | each x isNil]) first pointersTo points me to recreateSpecialObjectsArray I looked into the literals and others and I could not find. Each time I execute Smalltalk recreateSpecialObjectsArray I get a new nil@nil objects.... but forcing a GC garbage them. But I still have this nil@nil object around. Does anybody have an idea from where nil@nil could come from? Stef

April 21, 2011

[Pharo-project] [update 1.3] #13169

by Marcus Denker

13169 ----- Issue 2927: formFromServerFile -> a better little helper Issue 3431: Faster traitNames Issue 4066: MNU when saving in monticello and no package is selected -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 21, 2011

[Pharo-project] Updated the the Cog Google code and Gitorious home pages

by Mariano Martinez Peck

Hi guys. Cog info is a little spread in different places. I've just updated the home pages of: https://gitorious.org/cogvm http://code.google.com/p/cog/ I put all the interested links so that at least we can jump from one place to another other one. If you (Eliot?) feel more links or info should be put, please let me know. Best regards, -- Mariano http://marianopeck.wordpress.com

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by Oscar E A Callau

Thank you very much Sven, I think this must be include in the pharo book, because it was hard to find good examples. Cheers. On Apr 21, 2011, at 08:22 , Sven Van Caekenberghe wrote: > Oscar, > > This is how I would write it, using first SocketStreams (which is better for most users) and then plain Sockets. This works for me on Pharo 1.2.2 and 1.3. > > HTH, > > Sven > > > | serverSocket dataSent dataRead clientStream semaphore | > semaphore := Semaphore new. > serverSocket := Socket newTCP listenOn: 9191 backlogSize: 5. > [ [ | clientSocket serverStream | > clientSocket := serverSocket waitForAcceptFor: 10. > serverStream := SocketStream on: clientSocket. > dataRead := serverStream upToEnd. > serverStream close. > semaphore signal ] ensure: [ serverSocket close ] ] forkAt: Processor userBackgroundPriority. > (Delay forMilliseconds: 100) wait. > dataSent := 'Hello there!'. > clientStream := SocketStream openConnectionToHostNamed: 'localhost' port: 9191. > clientStream nextPutAll: dataSent. > clientStream close. > semaphore wait. > self assert: dataSent = dataRead. > dataRead > > > > | serverSocket clientSocket dataSent dataRead semaphore | > semaphore := Semaphore new. > serverSocket := Socket newTCP listenOn: 9191 backlogSize: 5. > [ [ | clientConnectionSocket | > clientConnectionSocket := serverSocket waitForAcceptFor: 10. > dataRead := clientConnectionSocket receiveData. > clientConnectionSocket close. > semaphore signal ] ensure: [ serverSocket close ] ] forkAt: Processor userBackgroundPriority. > (Delay forMilliseconds: 100) wait. > dataSent := 'Hello there!'. > clientSocket := Socket newTCP connectToHostNamed: 'localhost' port: 9191. > clientSocket sendData: dataSent. > clientSocket close. > semaphore wait. > self assert: dataSent = dataRead. > dataRead > > > > On 21 Apr 2011, at 15:04, Oscar E A Callau wrote: > >> >> Thanks all for your comments. >> >> On Apr 21, 2011, at 07:13 , Sven Van Caekenberghe wrote: >>> >>> I think the problem might be the #listenOn: >>> I use #listenOn:backlogSize: >>> These are using different primitives. >> >> I tested with #listenOn:backlogSize: too, with the same result, error on #waitForAcceptFor: . >> >> Cheers >> >> >

April 21, 2011

[Pharo-project] Balloon engine and bitmap fills: any clues why it ignores an alpha channel of bitmap?

by Igor Stasenko

I tried various paint rules 24, 34 nothing. A balloon engine seems like completely ignores an alpha channel, so i could use it for filling shapes using bitmaps as long as these bitmaps fully opaque. I thought i could use a generic way to render bitmaps, instead of using awkward warpBlt... but it seems like something in plugin discards/ignores an alpha channel of source bitmap. I would be happy if this is not true. -- Best regards, Igor Stasenko AKA sig.

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by StÃ©phane Ducasse

Yes!!!! I forwarded that mail to the network chapter authors. and we will really ask for feedback Stef On Apr 21, 2011, at 4:06 PM, Oscar E A Callau wrote: > Thank you very much Sven, I think this must be include in the pharo book, because it was hard to find good examples. > > > Cheers. > > > On Apr 21, 2011, at 08:22 , Sven Van Caekenberghe wrote: > >> Oscar, >> >> This is how I would write it, using first SocketStreams (which is better for most users) and then plain Sockets. This works for me on Pharo 1.2.2 and 1.3. >> >> HTH, >> >> Sven >> >> >> | serverSocket dataSent dataRead clientStream semaphore | >> semaphore := Semaphore new. >> serverSocket := Socket newTCP listenOn: 9191 backlogSize: 5. >> [ [ | clientSocket serverStream | >> clientSocket := serverSocket waitForAcceptFor: 10. >> serverStream := SocketStream on: clientSocket. >> dataRead := serverStream upToEnd. >> serverStream close. >> semaphore signal ] ensure: [ serverSocket close ] ] forkAt: Processor userBackgroundPriority. >> (Delay forMilliseconds: 100) wait. >> dataSent := 'Hello there!'. >> clientStream := SocketStream openConnectionToHostNamed: 'localhost' port: 9191. >> clientStream nextPutAll: dataSent. >> clientStream close. >> semaphore wait. >> self assert: dataSent = dataRead. >> dataRead >> >> >> >> | serverSocket clientSocket dataSent dataRead semaphore | >> semaphore := Semaphore new. >> serverSocket := Socket newTCP listenOn: 9191 backlogSize: 5. >> [ [ | clientConnectionSocket | >> clientConnectionSocket := serverSocket waitForAcceptFor: 10. >> dataRead := clientConnectionSocket receiveData. >> clientConnectionSocket close. >> semaphore signal ] ensure: [ serverSocket close ] ] forkAt: Processor userBackgroundPriority. >> (Delay forMilliseconds: 100) wait. >> dataSent := 'Hello there!'. >> clientSocket := Socket newTCP connectToHostNamed: 'localhost' port: 9191. >> clientSocket sendData: dataSent. >> clientSocket close. >> semaphore wait. >> self assert: dataSent = dataRead. >> dataRead >> >> >> >> On 21 Apr 2011, at 15:04, Oscar E A Callau wrote: >> >>> >>> Thanks all for your comments. >>> >>> On Apr 21, 2011, at 07:13 , Sven Van Caekenberghe wrote: >>>> >>>> I think the problem might be the #listenOn: >>>> I use #listenOn:backlogSize: >>>> These are using different primitives. >>> >>> I tested with #listenOn:backlogSize: too, with the same result, error on #waitForAcceptFor: . >>> >>> Cheers >>> >>> >> > >

April 21, 2011

Re: [Pharo-project] Networking problems on Pharo 1.2.1

by Oscar E A Callau

Thanks all for your comments. On Apr 21, 2011, at 07:13 , Sven Van Caekenberghe wrote: > > I think the problem might be the #listenOn: > I use #listenOn:backlogSize: > These are using different primitives. I tested with #listenOn:backlogSize: too, with the same result, error on #waitForAcceptFor: . Cheers

April 21, 2011

Re: [Pharo-project] out of memory - cog on windows

by Luc Fabresse

Hi Doru, 2011/4/21 Tudor Girba <tudor.girba(a)gmail.com> > Hi, > > > > On Apr 21, 2011, at 14:06, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba < <tudor.girba(a)gmail.com> > tudor.girba(a)gmail.com> wrote: > >> > Hi again, >> > >> > I did not say what the problem was :). The problem was that when opening >> the image on Windows, he got a Space is low message and the image was not >> usable (see attachment). > > > That's weird. Does moose have something on the startup list? something > that can be bothering there? > > > Not that I know of. Is there a way to check this? > Classes should be registered using Smalltlak addToStartUpList: aClass Then aClass class>>#startUp: is executed at startup. So implementors of #startUp: on Moose classes should give you the answer. #Luc > Actually, using exactly the same process some days ago he produced an image > of 190MB. This one works just fine on Windows. The only difference between > the two is the size of the loaded data. > > It would be really bad news if the Windows vm would be so severely limited > in terms of memory. > > Cheers, > Doru > > > > >> On Mac it worked just fine. >> > >> > Cheers, >> > Doru >> > >> > >> >> > >> > >> > >> > On 21 Apr 2011, at 12:52, Tudor Girba wrote: >> > >> >> Hi, >> >> >> >> I received a question from someone running a 200MB image on Windows >> using Cog 2361. >> >> >> >> If I open the image on Mac, it works just fine. Unfortunately, I do not >> have a Windows machine around, and I cannot test but I believe it should be >> solvable by increasing the allocated memory. >> >> >> >> On Mac, I would run it with: ./Croquet -memory 1500m >> >> >> >> Can anyone help me with the right incantation for Windows? >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >> -- >> >> <http://www.tudorgirba.com>www.tudorgirba.com >> >> >> >> "What we can governs what we wish." >> >> >> >> >> >> >> >> <Space is low.png> >> > >> > -- >> > <http://www.tudorgirba.com>www.tudorgirba.com >> > >> > "Yesterday is a fact. >> > Tomorrow is a possibility. >> > Today is a challenge." >> > >> > >> > >> >> > > > -- > Mariano > <http://marianopeck.wordpress.com>http://marianopeck.wordpress.com > >

April 21, 2011