April 2011 - Pharo-dev - lists.pharo.org

[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

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

by Sven Van Caekenberghe

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] out of memory - cog on windows

by Tudor Girba

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> 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? 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 > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "What we can governs what we wish." > >> > >> > >> > >> <Space is low.png> > > > > -- > > www.tudorgirba.com > > > > "Yesterday is a fact. > > Tomorrow is a possibility. > > Today is a challenge." > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 21, 2011

[Pharo-project] squeaksource is down

by Mariano Martinez Peck

thanks -- Mariano http://marianopeck.wordpress.com

April 21, 2011

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

by Mariano Martinez Peck

On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba <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? > 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 > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "What we can governs what we wish." > >> > >> > >> > >> <Space is low.png> > > > > -- > > www.tudorgirba.com > > > > "Yesterday is a fact. > > Tomorrow is a possibility. > > Today is a challenge." > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 21, 2011

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

by Tudor Girba

> 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). 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 >> >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> <Space is low.png> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > >

April 21, 2011

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

by Sven Van Caekenberghe

On 21 Apr 2011, at 12:42, Stephan Eggermont wrote: > That is no networking problem. That is just how a tcp server connections work. > When you connect from a client to the server, the server has to initialize a new > socket to communicate on. Just take a look at what waitForConnectionFor does. > > Stephan I don't agree, accept is what a server does for a socket that is listening, connecting is what a client does. The code is not as I would write it (it is wrong to create server sockets in a loop). One also has to be careful with multithreading and who is waiting for who. I think the problem might be the #listenOn: I use #listenOn:backlogSize: These are using different primitives. Sven

April 21, 2011