October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Getting my head around low space

by Max Leske

I had a first failure with 1 GB. I used the 4.2.5b1U VM. Setting the memory to anything above 1 GB would lead to an error message. I'm now trying the 5.7b1 VM with 3.5 GB. Max On 10.10.2010, at 06:51, John M McIntosh wrote: > It's fairly clear: " the Mac VM has an option -memory" > no -mmap > > use it or set the info.plist setting of SqueakMaxHeapSize. > You can in theory set values up to 4GB on a 4.2.x VM or 5.7.x > Might make lights dim and core dump on a 5.8.x VM, please try... > Obviously you have to actually use the 4GB of memory. > > However I suspect asking for anything close to or over 5.8GB on a 4.2.x and 5.8.x VM won't fly. > Should work with a 5.7.x VM > > > On 2010-10-09, at 8:14 PM, Levente Uzonyi wrote: > >> On Sat, 9 Oct 2010, Max Leske wrote: >> >>> I'm actually working on a mac, so that shouldn't be the problem. >>> So your proposition to use -mmap would be unix specific? Is the option available on mac? >> >> I don't have a Mac, but you can easily check it by starting an image with "-mmap 64m", then allocating a 64MB array in the image. If it fails, then the switch works, otherwise not. >> >> >> Levente >> >>> >>> Thanks, >>> Max >>> >>> >>> On 09.10.2010, at 21:34, Levente Uzonyi wrote: >>> >>>> On Sat, 9 Oct 2010, Adrian Lienhard wrote: >>>> >>>>> The unix VM and apparently also the Mac VM has an option -memory that allows you to set a heap size: >>>>> >>>>> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ VM\ Opt -help >>>>> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] >>>>> ./Squeak VM Opt [<option>...] -- [<argument>...] >>>>> >>>>> Common <option>s: >>>>> -help print this help message, then exit >>>>> -memory <size>[mk] use fixed heap size (added to image size) >>>>> -pathenc <enc> set encoding for pathnames (default: macintosh) >>>>> -headless run in headless (no window) mode (default: false) >>>>> >>>>> Notes: >>>>> <imageName> defaults to `Squeak.image'. >>>>> If `-memory' is not specified then the heap will grow dynamically. >>>>> <argument>s are ignored, but are processed by the Squeak image. >>>>> The first <argument> normally names a Squeak `script' to execute. >>>>> Precede <arguments> by `--' to use default image. >>>> >>>> This is ok for Mac, but the unix VM takes different arguments. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> >>>>> HTH, >>>>> Adrian >>>>> >>>>> On Oct 9, 2010, at 18:01 , Max Leske wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. >>>>>> >>>>>> Thanks for any ideas. >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> _______________________________________________ >>>>>> 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 > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Levente Uzonyi

On Sun, 10 Oct 2010, Igor Stasenko wrote: > A current implementation of this method > > remove: oldObject ifAbsent: exceptionBlock > "Remove oldObject as one of the receiver's elements." > > oldObject ifNil: [ ^nil ]. > ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) > ifNil: [ exceptionBlock value ] > > simply removes a previously registered object from registry and voila. > > Now lets get back to our discussion about multiple finalizers per > object and using them in weak subscriptions etc. > > Suppose i am added a socket to weak registry, > and suppose i am added a weak subscription to it. > > Now, if i do 'socket close' , it tells weak registry to remove it from list. > And what we'll have: > - socket handle is closed > - socket is wiped from weak registry > - but weak subscription still listed somewhere in a list of subscriptions > > > My suggestion is, that upon #remove:, > a weak registry should notify all executors that object of interest > are no longer takes part in finalization scheme, > so they should not count on receiving #finalize eventually. > > In other words: > > remove: oldObject ifAbsent: exceptionBlock > "Remove oldObject as one of the receiver's elements." > > oldObject ifNil: [ ^nil ]. > ^(self protected: [ | executor | > executor := valueDictionary removeKey: oldObject ifAbsent: nil. > executor discardFinalization. > ]) > ifNil: [ exceptionBlock value ] It's only an issue with the new WeakRegistry implementation, previous implementations don't have such problem. I think changing the method as you suggested, implementing WeakFinalizerItem >> #discardFinalization as "executor := nil" and changing WeakFinalizerItem >> #finalizaValues to ignore the executor if it's nil will fix the problem. Am I right? I don't get how "multiple finalizers per object" is related to this problem at all. Levente > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

On Oct 10, 2010, at 3:07 PM, Igor Stasenko wrote: > On 10 October 2010 15:39, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> > +1 > > i am also missing: > > someThing ifTrue: 1 ifFalse: 0 I hate this idea. Let the compiler doing optimizations and please do not mix implementation and language design. The ***semantics*** of iftrue: is to get a thunk (in scheme parlance) something whose evaluation is blocked. 1 is not that! Now the compiler could be smart and inline whatever. Stef

Oct. 10, 2010

[Pharo-project] Xtreams port to Squeak - second wave

by Nicolas Cellier

Hi again, I now have ported two more packages - Xtreams-Transforms - Xtreams-Substreams and their tests I did not have any portability problem with those... But that's because I did not handle the Character encoder/decoder. Consequently, I have 8 tests failing (the Base64 related tests) Plus 4 other tests failing because of my poor implementation of #after:do: (forking processes in a SUnit TestCase can't be that obvious). Now, the easy part of the port (copy/paste) is almost ended. Once we manage a compatible way to handle pragmas, PEG Parser should port quite easily too. Then, the harder work begins: - File/Socket/Pipe - Pointers (in External Heap) - Character encoding/decoding - Compression/Decompression If you think you can help in any of these, please tell. Nicolas

Oct. 10, 2010

Re: [Pharo-project] Smalltalk Interchange Format [was Xtreams : first embryonary port on Squeak]

by Schwab,Wilhelm K

Nicolas, Can you get sifall.zip? That's what I use. Sadly I am not sure about the license, so while I have no worries about directing you to the source, I am not in a hurry to host it myself. It's old, but I was impressed at how well it worked at getting code out of Dolphin. Pharo/MC acts a little badly about some of the *xzy category names that result, but nothing so bad that you can't fix them with a text editor, the regex package, or by browsing/editing offending names. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 10, 2010 2:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Smalltalk Interchange Format [was Xtreams : first embryonary port on Squeak] Thanks Bill, some of the link on this page seem dead though... Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > FWIW, SIF might help you: > > http://www.pocketsmalltalk.com/sif/ > > I have put a lot of code through it in the past couple of years. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Saturday, October 09, 2010 6:33 PM > To: The general-purpose Squeak developers list; Pharo Development; vwnc(a)cs.uiuc.edu > Subject: [Pharo-project] Xtreams : first embryonary port on Squeak > > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. > > cheers > > Nicolas > > --------------------- REPORT --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > > _______________________________________________ > 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

Oct. 10, 2010

Re: [Pharo-project] [OT] database choices

by Philippe Marschall

On 10.10.2010 20:38, Schwab,Wilhelm K wrote: > Just learned about this one: > > http://mariadb.org/index.html > > It sounds like the old guard of MySQL is coalescing around it. It's up to you to decide whether that is true, and if so, whether it is a good thing. It's funny because for years Oracle has been making the only usable MySQL engine: InnoDB. Cheers Philippe

Oct. 10, 2010

Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ]

by Schwab,Wilhelm K

Nicolas, I'm told there is no such thing as a free lunch<g>, but if you tell me what you want the menu to look like, I might have something that would be useful. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 10, 2010 2:45 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ] Hi Bill, I see, you're helping me to help myself :) What I was looking at was more like a free lunch ;) Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > #fork in a test? Do you mean like the code below? The thread running the test waits on something signaled toward the end of the forked thread. > > If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned. > > Does that help? > > Bill > > > testLocalServerAndClient > "11-09 - try a server and a client in the same image." > > | server port client serverSocket serverSocketStream text thread done read | > > port := 4900. > done := Semaphore new. > > "11-09 - gag the prompter below" > serverSocket := nil. > > server := ConnectionQueue portNumber:port queueLength:5. > [ > client := SocketStream openConnectionToHostNamed:'localhost' port:port. > [ serverSocket isNil ] whileTrue:[ > serverSocket := server getConnectionOrNil. > ]. > > serverSocketStream := SocketStream on:serverSocket. > text := 'Long live Tux!'. > serverSocketStream nextPutAll:text; flush. > > "11-09 - this hung up w/o the thread. > 11-09 - as you were; the problem was a lack of #flush on the send side, so there was > nothing for the client side to read." > thread := [ > read := client nextMany:text size. > done signal. > ] forkAt:Processor userBackgroundPriority. > thread name:'READ'. > > done wait. > self should:[ read = text ]. > Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush. > > ] ensure:[ > server destroy. > serverSocketStream close. > client close. > ]. > > "11-09 - no prompts" > serverSocket := serverSocket. > client := client. > serverSocketStream := serverSocketStream. > thread := thread. > > " > NetworkSmokeTestCase prod:#testLocalServerAndClient. > " > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Sunday, October 10, 2010 7:05 AM > To: The general-purpose Squeak developers list > Cc: Pharo Development > Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak > > 2010/10/10 Levente Uzonyi <leves(a)elte.hu>: >> On Sun, 10 Oct 2010, Nicolas Cellier wrote: >> >>> >>> THE STATUS OF TESTS: >>> >>> Tests do not all pass. There seems to be a bug in Squeak >>> #replace:from:to:with: when the replacement is the collection itself, >>> moved to the right (this is with a COG VM). >> >> #replace:from:to:with: is not supposed to work for moves. IIRC the primitive >> version uses memcpy (or strncpy), so moving to the left works just because >> the undelying C function supports it. I used to (ab)use this feature though. >> >> >> Levente >> > > OK, since we use memcpy rather than memmove in Squeak VM, I > implemented the trivial work around - move through a motionBuffer > temporary copy. > > I now have a single test failing, > XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be > due to my #after:do: simplistic implementation. > Messing with #fork in SUnit TestCase is tricky, and I need help on this point. > > Nicolas > > _______________________________________________ > 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

Oct. 10, 2010

Re: [Pharo-project] Smalltalk Interchange Format [was Xtreams : first embryonary port on Squeak]

by Nicolas Cellier

Thanks Bill, some of the link on this page seem dead though... Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > FWIW, SIF might help you: > > Â http://www.pocketsmalltalk.com/sif/ > > I have put a lot of code through it in the past couple of years. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Saturday, October 09, 2010 6:33 PM > To: The general-purpose Squeak developers list; Pharo Development; vwnc(a)cs.uiuc.edu > Subject: [Pharo-project] Xtreams : first embryonary port on Squeak > > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. > > cheers > > Nicolas > > --------------------- REPORT Â --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Â Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > > _______________________________________________ > 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 >

Oct. 10, 2010

Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ]

by Nicolas Cellier

Hi Bill, I see, you're helping me to help myself :) What I was looking at was more like a free lunch ;) Nicolas 2010/10/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > #fork in a test? Â Do you mean like the code below? Â The thread running the test waits on something signaled toward the end of the forked thread. > > If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. Â You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. Â You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned. > > Does that help? > > Bill > > > testLocalServerAndClient > Â Â Â Â "11-09 - try a server and a client in the same image." > > Â Â Â Â Â Â Â Â | server port client serverSocket serverSocketStream text thread done read | > > Â Â Â Â port := 4900. > Â Â Â Â done := Semaphore new. > > Â Â Â Â "11-09 - gag the prompter below" > Â Â Â Â serverSocket := nil. > > Â Â Â Â server := ConnectionQueue portNumber:port queueLength:5. > Â Â Â Â [ > Â Â Â Â Â Â Â Â client := SocketStream openConnectionToHostNamed:'localhost' port:port. > Â Â Â Â Â Â Â Â [ serverSocket isNil ] whileTrue:[ > Â Â Â Â Â Â Â Â Â Â Â Â serverSocket := server getConnectionOrNil. > Â Â Â Â Â Â Â Â ]. > > Â Â Â Â Â Â Â Â serverSocketStream := SocketStream on:serverSocket. > Â Â Â Â Â Â Â Â text := 'Long live Tux!'. > Â Â Â Â Â Â Â Â serverSocketStream nextPutAll:text; flush. > > Â Â Â Â Â Â Â Â "11-09 - this hung up w/o the thread. > Â Â Â Â Â Â Â Â 11-09 - as you were; the problem was a lack of #flush on the send side, so there was > Â Â Â Â Â Â Â Â nothing for the client side to read." > Â Â Â Â Â Â Â Â thread := [ > Â Â Â Â Â Â Â Â Â Â Â Â read := client nextMany:text size. > Â Â Â Â Â Â Â Â Â Â Â Â done signal. > Â Â Â Â Â Â Â Â ] forkAt:Processor userBackgroundPriority. > Â Â Â Â Â Â Â Â thread name:'READ'. > > Â Â Â Â Â Â Â Â done wait. > Â Â Â Â Â Â Â Â self should:[ read = text ]. > Â Â Â Â Â Â Â Â Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush. > > Â Â Â Â ] ensure:[ > Â Â Â Â Â Â Â Â server destroy. > Â Â Â Â Â Â Â Â serverSocketStream close. > Â Â Â Â Â Â Â Â client close. > Â Â Â Â ]. > > Â Â Â Â "11-09 - no prompts" > Â Â Â Â serverSocket := serverSocket. > Â Â Â Â client := client. > Â Â Â Â serverSocketStream := serverSocketStream. > Â Â Â Â thread := thread. > > Â Â Â Â " > Â Â Â Â Â Â Â Â NetworkSmokeTestCase prod:#testLocalServerAndClient. > Â Â Â Â " > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Sunday, October 10, 2010 7:05 AM > To: The general-purpose Squeak developers list > Cc: Pharo Development > Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Â Â Squeak > > 2010/10/10 Levente Uzonyi <leves(a)elte.hu>: >> On Sun, 10 Oct 2010, Nicolas Cellier wrote: >> >>> >>> THE STATUS OF TESTS: >>> >>> Tests do not all pass. There seems to be a bug in Squeak >>> #replace:from:to:with: when the replacement is the collection itself, >>> moved to the right (this is with a COG VM). >> >> #replace:from:to:with: is not supposed to work for moves. IIRC the primitive >> version uses memcpy (or strncpy), so moving to the left works just because >> the undelying C function supports it. I used to (ab)use this feature though. >> >> >> Levente >> > > OK, since we use memcpy rather than memmove in Squeak VM, I > implemented the trivial work around - move through a motionBuffer > temporary copy. > > I now have a single test failing, > XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be > due to my #after:do: simplistic implementation. > Messing with #fork in SUnit TestCase is tricky, and I need help on this point. > > Nicolas > > _______________________________________________ > 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 >

Oct. 10, 2010

[Pharo-project] [OT] database choices

by Schwab,Wilhelm K

Just learned about this one: http://mariadb.org/index.html It sounds like the old guard of MySQL is coalescing around it. It's up to you to decide whether that is true, and if so, whether it is a good thing.

Oct. 10, 2010