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

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

> > > Stef and I worked on an implementation a few years ago. > http://www.squeaksource.com/Namespace.html And it is a bad one :) Now we are working on making the system environment-aware so that we can browse part of the system, (remotely too with you). Stef > > Cheers, > Alexandre > > > On 11 Oct 2010, at 07:53, Nick Papoylias wrote: > >> Hallo to all, >> >> I am starting my Ph.D on 'languages and environments for autonomous robotics' -- and pharo will be a huge part of it. >> >> I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of >> different namespaces / environments. >> >> Specifically I am trying to find out what the implications of having a remote environment over rST for e.g (to browse, debug e.t.c). >> >> Any pointers to related work, suggestions e.t.c are welcomed. >> >> So my question: >> >> Is anybody currently working on integrating namespaces in the system level ? I may have one or two questions and suggestions to make. >> >> Thank you very much ! >> >> Nick Papoulias >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] [update 1.2] #12189
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

12189 ----- - Issue 2883: Anymorphic Style. Thanks Anymorphic and Nicolas Paez. - Issue 2979: Controlling UI feedback. BlockClosure>>silentlyValue

1 0

Re: [Pharo-project] MicroSqueak [was System Tracer]
by Eliot Miranda Oct. 11, 2010

Oct. 11, 2010

FInd attached. You want MicroSqueak-colonequal.st and the various MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 development image which will run on a 3.8 VM. Let me know if you want that. For me this is a proof of concept. What's needed is to define a headless core that contains the compiler, good error reporting to standard out, the core collection and numeric libraries and file support. Then we try and load packages into it and build up a headful image. On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > > > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > generate a new image. > > > > But that's not what it does. > > Yes I know gnerates = clone in my mail. > > > t merely clones an image, which is a long way form building an image > form source. *That*'s a useful project. John Maloney's lovely MicroSqueak > is a good starting point for ideas (basically have a copy of a kernel subset > of the system in a namespace and generate a fresh image from that). > > Do you have a pointer on the code of john. We are looking at bootstrap code > right now. > > > > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > > > Hi! > > > > > > What do you want to achieve? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > > > >> Hi > > >> > > >> Does anyone know where I can find the system tracer that is currently > > >> in use in Pharo? > > >> > > >> Bests > > >> Gabriel > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 >

2 5

[Pharo-project] WeakRegistry>>remove: - when you'll be in trouble
by Igor Stasenko Oct. 11, 2010

Oct. 11, 2010

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 ] -- Best regards, Igor Stasenko AKA sig.

4 9

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

>> >> >> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >> Too many hacks will only make the system more hackish. >> And especially the >> iftrue: 'foo' ifFalse: 'zork' >> > > This is not a hack, because if you refer to implementation: > > True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^trueAlternativeBlock value > > False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^falseAlternativeBlock value > > so, it answers either 'foo' value , or 'zork' value. > And #value could be sent to any object in system: > > Object>>value > ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. I know well that. and it sucks from a language semantics point of view. I agree with the mail of lukas. Stef

2 1

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

On Oct 11, 2010, at 1:28 PM, Lukas Renggli wrote: >> Object>>value >> ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > Magritte implemented Symbol>>#value: for a while before any Smalltalk > had this is their standard library. I must admit that I liked it in > the beginning, but in the long run I realized that ... > > 1. It is not easily understandable for newbies. > 2. It quickly leads to very unreadable, hard to understand and hard to > refactor code. > 3. It is very limiting in itself and quickly leads to other hacks > (like to replace sort blocks). > 4. #value and friends should be only understood by objects that can be > evaluated (certainly not by Object). A symbol (name) by itself cannot > be evaluated. + 200 > I eventually removed Symbol>>#value: for good. Re-occuring questions > in the mailing list disappeared. > > Therefor I strongly suggest to remove #value, #value:, and friends > from all objects that are not self-evaluable. BlockClosure and > MessageSend are self-evaluable. Only there it makes sense. > > If people are too lazy to create a block where something > self-evaluable is needed they should use a programming language > designed for cryptic code. Creating a block closure in Smalltalk is > concise and makes clear what happens easily. A symbol does not, you > need to exactly understand how this dispatches with various objects. This is exactly my point. Especially for system API like ifNotNil: When I read self bar: #zook I just know ok we are just passing a symbol as argument. I do not have to rely on the semantics of bar: so this is the only conclusion I can draw. Now I do not want to force people to have to understand the semantics of each single selector. In addition, it breaks nice rule such as use [ ] for any place where you do not know if the code will be executed. Simple nice and beautiful. [..]s delay execution and let the guy control it. Stef

1 0

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

Hi we should improve from that side, but unfortunately we do not have enough man power to build tool that could support it. Stef On Oct 11, 2010, at 1:28 PM, Johannes Rasche wrote: > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! > > Thanks in advance > > > > > Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > > mail: johannesrasche(a)me.com > skype: johannesrasche > www: http://myNeat.de > fon: +49-30-7469 4425 (skypeIn) > fax: +49-30-315 66 821 > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] another little OB "bug"
by Mariano Martinez Peck Oct. 11, 2010

Oct. 11, 2010

Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no problem then ;) Suppose you are working with a method that it is in the half of the method pane of OB. Once you save it or run test on it for example, the "scroll" and the method pane is updated so that THAT method is first, above. And sometimes this is quite annoying for me. Cheers Mariano

2 4

[Pharo-project] Xtreams : first embryonary port on Squeak
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

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.

4 5

Re: [Pharo-project] 12186 image quit problem
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

Thanks. So let's see what is the best choice and tell us. On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > On 11 October 2010 12:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I integrate >> Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> http://code.google.com/p/pharo/issues/detail?id=3086 >> >> >> >> Igor can you have a look and let me know: >> 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> 2- if we should integrate >> Issue 3048: MC method cache fix >> http://code.google.com/p/pharo/issues/detail?id=3048 >> >> I will integrate >> http://code.google.com/p/pharo/issues/detail?id=3091 >> > > Wait , MCMethodDefinition is only a consequence (however, removing it > from weakdependents would be good idea as well ;)). Yes I integrate it to avoid system hanging. > The real cultprit is HostSystemMenusProxy , which locks the weak > registry during finalization. > Then MCMethodDefinition>>shutdown simply locks at same point (trying > to obtain semaphore lock). > Note, that HostSystemMenusProxy locks finalization process, but not > the process which doing shutdown, > and then during image startup, a new finalization process get created. > That's why removing access to weakdependents in > MCMethodDefinition>>shutdown , kinda solved the issue. > In reality its not. > An old weak registry were sending #finalize outside a critical section: > > finalizeValues > "Some of our elements may have gone away. Look for those and activate > the associated executors." > | finiObjects | > finiObjects := nil. > "First collect the objects." > self protected:[ > valueDictionary allAssociationsDo:[:assoc| > assoc key isNil ifTrue:[ > finiObjects isNil > ifTrue:[finiObjects := OrderedCollection with: assoc value] > ifFalse:[finiObjects add: assoc value]] > ]. > finiObjects isNil ifFalse:[valueDictionary finalizeValues: > finiObjects asArray]. > ]. > "Then do the finalization" > finiObjects isNil ifTrue:[^self]. > finiObjects do:[:each| each finalize]. > > > So, there two ways to solve it: > a) perform finalization outside a critical section (see attached) > b) fix the HostSystemMenusProxy to prevent any manupulation with weak > registry during finalization. > > > I checked Squeak 4.2 image, and i can also say, that any attempt to > manipulate weak registry during finalization will also lock down a > finalization process (see Squeak's WeakRegistry>>finalizeValues & > WeakKeyDictionary>>finalizeValues) > > So, if we going to assume, in future that it is error to modify weak > registry during finalization, then we should leave the code in > WeakRegistry as-is, and fix HostSystemMenusProxy instead. > If not, the we should make sure that #finalize should be sent outside > weak registry's critical section. > > And the last note: if VM supports new finalization, it will happen > outside a critical section (See the > bottom of WeakRegistry>>finalizeValues). So any manipulations with > registry during finalization can't cause lockdown. > > > P.S. forwarded to Squeak-dev, to make Squeakers aware of potential > danger , when manipulating weak registry during finalization. > > -- > Best regards, > Igor Stasenko AKA sig. > <WeakRegistry-finalizeValues.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] 12186 image quit problem
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

I integrate Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. http://code.google.com/p/pharo/issues/detail?id=3086 Igor can you have a look and let me know: 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. 2- if we should integrate Issue 3048: MC method cache fix http://code.google.com/p/pharo/issues/detail?id=3048 I will integrate http://code.google.com/p/pharo/issues/detail?id=3091 Stef > Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 > > The patch works for me, Thank you Igor. > > Cheers, > -- Pavel > > On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > > Sent: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

personnally I do not like this form What does it do? > process ifNotNil: #terminate. for me it means passes the symbol #terminate as argument to the method ifNotNil: If it has a more magical behavior then I do not know it. Stef > 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. > > cheers > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 4

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

> > > ? > In any way, passing anything else than block literal as argument should work. You mean in the implementation or in the semantics? Read my mail. This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution). > This is smalltalk, not C with static types. consistency and elegance as nothing to do with absence of static types. With such a change we can break a lot of uniformity and break potential type inferencers. And I do not see the advantage, beside having a clunky system. Stef

1 0

Re: [Pharo-project] 12186 image quit problem
by Marcus Denker Oct. 11, 2010

Oct. 11, 2010

On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: > Hmm, this is the result for Linux and > cogvm 3.9-7 and pharovm 3.10-3 > > can you try: https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 30

[Pharo-project] Xtreams port to Squeak - second wave
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

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

3 2

[Pharo-project] bad bracket autocompletion in Pharo Core 1.2
by Guillermo Polito Oct. 11, 2010

Oct. 11, 2010

http://code.google.com/p/pharo/issues/detail?id=3069 if you type: [] -> []] () -> ()) {} -> {}} Bye!

4 6

Re: [Pharo-project] Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding I just published XtreamsDevelopment(387) with following changes: * abstracted Encoder out of encoded streams to allow implementing our own encodings. * Encoder.Encoders registers known encoders * Encoder.DialectEncoder provides a hook to access dialect specific encoders * added ASCIIEncoder implementing ASCII encoding portably * added VWEncoder wrapping VisualWorks StreamEncoders Obviously VWEncoder won't work in Squeak and should eventually move to a VW specific package. But at the moment it might be useful as an example of how to take advantage of the existing encoders in Squeak. I briefly looked at the Multilingual categories in Pharo and there seem to be quite a few encodings available through the TextConverter hierarchy. You've expressed some reservations about that, but it might be worth taking advantage of those at least initially. Anyway with the above there should be at least an #ascii encoder available for now.

1 0

[Pharo-project] Fwd: [squeak-dev] Re: WeakRegistry>>remove: - when you'll be in trouble
by Igor Stasenko Oct. 11, 2010

Oct. 11, 2010

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> 2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >> On Mon, 11 Oct 2010, Igor Stasenko wrote: >> >>> On 10 October 2010 23:43, Levente Uzonyi <leves(a)elte.hu> wrote: >>> 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. >>> >> >> No, you miss the point. >> When you removing object from weak registry, it is important , time to >> time to tell all of its executors, >> that they will no longer receive #finalize, because object is no >> longer a member of weak registry. >> >> If you simply set executor := nil, it does nothing, an executor itself >> did not notified that he won't be needed >> in any possible future. >> So, if your finalization action is to remove some object(s) from the >> list , you'll get your list dirty after object will die, >> because #finalize will be never sent to your executor. >> >> Here the simple test case: >> >> | coll obj someWrapper | >> coll := OrderedCollection new. >> obj := Object new. >> someWrapper := WeakArray with: obj. >> coll add: someWrapper. >> >> obj toFinalizeSend: #remove: to: coll with: someWrapper. >> obj finalizationRegistry remove: obj. >> obj := nil. >> Smalltalk garbageCollect. >> self assert: coll isEmpty >> >> >> the point is, that once you doing a #remove: , >> your finalization scheme is broken. >> >> >> I don't get you. When you remove an object from a WeakRegistry, you tell >> the >> system that you want the object removed and all related executors deleted. >> So the executors should never receive #finalize, they should be thrown >> away. >> Even if there's action to be done with the executors (which is pointless >> IMHO since those will be thrown away, but who knows), doing them is the >> responsibility of the sender of #remove:. >> > > Let us get back to multiple finalizers per object, > when you have two separate places, which adding possibly different > executors for a single object > without knowing about each other (otherwise why would you want to add > two finalizers instead of one). > Now if one decides to do #remove: , > how to ensure that second one won't be left with dirty/invalid state? > > > It's not ensured, and it doesn't have to be. The sender of #remove: takes > all responsibility. It can decide to add some executors back to the registry > if that's necessary. > If you want to keep your executors safe from some other code, which may > #remove: your objects from a WeakRegistry, then you can create a private > WeakRegistry and store your executors there, just like Sockets and > FileStreams do. > Conclusion: weak registry don't have to support multiple finalizers per single object. Instead, if one sees the need to control a finalization of certain object(s) in own way, indepentently fron any other, then he should use a private weak registry (like Sockets and FileStreams do), and register object and its executor there. -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Pharo-project] Xtreams : first embryonary port on Squeak
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Schwab,Wilhelm K"<bschwab(a)anest.ufl.edu> wrote: > 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. I'd recommend giving the Monticello tools in VW a try before trying to put something together from lower level tools. It's used to keep Seaside in sync in VW, so it should handle most of the obvious obstacles. With the help of your Xtreams-VWCompatibility package on Squeak side and maybe some adjustments in the portable code and maybe moving some of the non-portable code into packages of their own, we should be able to make this largely automatic.

1 0

Oct. 10, 2010

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

2 1

Re: [Pharo-project] Smalltalk Interchange Format [was Xtreams : first embryonary port on Squeak]
by Nicolas Cellier Oct. 10, 2010

Oct. 10, 2010

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 >

2 1

[Pharo-project] [OT] database choices
by Schwab,Wilhelm K Oct. 10, 2010

Oct. 10, 2010

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.

2 1

Re: [Pharo-project] Help request on Xtreams tests with forked process [ was Xtreams : first embryonary port on Squeak ]
by Nicolas Cellier Oct. 10, 2010

Oct. 10, 2010

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 >

2 1

[Pharo-project] Compiler pedantic about ifNotNil: argument
by Nicolas Cellier Oct. 10, 2010

Oct. 10, 2010

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. cheers Nicolas

5 9

[Pharo-project] little bug in OB running tests
by Mariano Martinez Peck Oct. 10, 2010

Oct. 10, 2010

Hi Lukas. A lot of times, I run tests with cmd + t in OB and the test fails (mostly becuase I like doing TDD). When I press proceed and the test passes (green), the little point on the left of the method in OB, isn't painted with green color as it does when the test directly passes (withput a failure in the middle). Thanks Mariano

2 1