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

Re: [Pharo-project] Cmd-t in OB?

by Alexandre Bergel

>> better in my opinion: ConfigurationOfOmnibrowser loadLastVersion > > I think the indirection through project to preserve backwards > compatibility and to avoid generating lots of boilerplate in the > configuration classes is worth it. Could be, even though I do not immediately see if this implies really a lot of boilerplate code. I usually only want to load the last version or a particular version of an application. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi Marcus, > is that really all what happened between 12172 and 12186? > > update12186 > Issue 3071: fixing timestamp tests > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning > Issue 3063: removing explain > Issue 3039: There should not be any configuration on Core > It doesn't explain the problems with VM versions and in 12186 I cannot build > the PharoKernel (it hangs without error in unload phase) > -- Pavel > please , tell me if it keep hanging after you doing: WeakArray restartFinalizationProcess. it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore. -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Lukas Renggli

On 8 October 2010 15:56, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> ConfigurationOfOmnibrowser project load@*%$LatestCode > > better in my opinion: ConfigurationOfOmnibrowser loadLastVersion I think the indirection through project to preserve backwards compatibility and to avoid generating lots of boilerplate in the configuration classes is worth it. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Alexander LazareviÄ <laza(a)blobworks.com>: > This is reproducible for me if I do: > > Gofer new > Â squeaksource: 'MetacelloRepository'; > Â package: 'ConfigurationOfExternalWebBrowser'; > Â load. > > Â (Smalltalk at: #ConfigurationOfExternalWebBrowser) load > > Find the error log attached. During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well > > Alex > > 2010/10/8 Alexander LazareviÄ <laza(a)blobworks.com>: >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> 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. >>>> >>>> >>>> _______________________________________________ >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] WebBrowser

by Marcus Denker

> > It's part of the class creation template. The only useful aspect of its existence was that you got a warning if you forgot to change the name of the subclass in the template. > -> It was part of a test package. Test packages only contain tests and artefacts used *by tests*. -> The class has no class comment. My theory is it was just the *result* of someone forgetting to change the name of the subclass in the template, not an intended mechanism. The error message would be very strange, too. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Schwab,Wilhelm K

Levente, This was several years ago in the Windows VM. I recall both shouting at the rain with no echo at the time, and years later seeing something very close to what I had done. At the time, printAllStacks() existed (which was why I had a prayer of succeeding), but produced a very jumbled mess with linefeeds in the wrong places. I did something with adding a feed or two outside of a loop over semaphores and then adding conditionals to the feeds inside the loop. More or less; it's been a while. Great news that the vm offers a ready way to trigger printAllStacks(); there are times when it is VERY useful, and if I'm right about what started this discussion, this will be one of them. It can't hurt much if I'm wrong - the double #critical:/#wait pattern would simply not appear and we would then know something that isn't causing it :) About SIGUSR1 on Linux, is the idea to open a terminal and send kill with SIGUSR 1 to the correct process ID? Where does the dump go? I'm guessing it goes to stdout of the vm, not to the terminal that sent the signal?? That would mean that one would need to have run the vm from a terminal or otherwise have arranged in advance to capture the output. So far at least, I tend to use a terminal to launch Pharo only when I expect to want trace info (such as when debugging one of my numerical .so functions) or when I have a reproducible badness (which this appears to be). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Friday, October 08, 2010 9:44 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Schwab,Wilhelm K wrote: > That's good to know. It probably should be a lot easier than that. At least in the Windows vm, there is/was a debug menu (part of the vm's system menu) that would dump the stack for the active process; I hacked it to dump all of them rather than just one, fixed printAllStacks() along the way, and found my problem. Think of an end user machine; you don't want to have to, or might not be able to, install development tools just to get this type of basic information. It might simply be a way of ruling out problems, but it could be very important. It's a lot easier than that. On windows just select the appropriate menu item "Dump all processes" instead of "Dump call stack". On un*x you can send SIGUSR1 to the process of the VM to make it print all stacks. IIRC Cog uses this signal for another purpose, so it doesn't work with Cog. What was the problem with printAllStacks() that you had to fix? Levente > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Adrian Lienhard [adi(a)netstyle.ch] > Sent: Friday, October 08, 2010 8:21 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 12186 image quit problem > > You can attach gdb to the VM and then call printAllStacks(). > > HTH, > Adrian > > On Oct 8, 2010, at 14:07 , Schwab,Wilhelm K wrote: > >> Do you have access to anything that will dump the callstacks for "all" processes? One of my first encounters with the Squeak update streams was trying to provide patches to the dump code... Similar features appeared years later, I suspect unrelated to my efforts. What I did was hack the VM such that the dump (on the vm menu) gave all (non-dead IIRC) processes rather than just that for the active process; for it to be readable required some changes to when the dump adds a line feed. >> >> Seeing which threads are waiting on semaphores wrapped in critical sections can be a huge help in finding deadlocks. Get it to lock up, then ask the vm for the dump and look for the offenders. If we don't have this, we should. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza(a)blobworks.com] >> Sent: Friday, October 08, 2010 5:06 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 12186 image quit problem >> >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> 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. >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >> >> > Hi Marcus, >> > >> > is that really all what happened between 12172 and 12186? >> > >> > update12186 >> > Issue 3071: Â fixing timestamp tests >> > Issue 3068: Â Non portable SmalltalkImage>>platformName >> > deprecationWarning >> > Issue 3063: Â removing explain >> > Issue 3039: Â There should not be any configuration on Core >> > >> > It doesn't explain the problems with VM versions and in 12186 I cannot >> > build the PharoKernel (it hangs without error in unload phase) >> > >> No, we loaded: >> >> Issue 3002: Â Â A new finalization code ready for integration in Pharo >> http://code.google.com/p/pharo/issues/detail?id=3002 > > ok, can you reproduce this on your VM? > - take prebuilt 12186 > - run the image with a file as argument that contains: > Â SmalltalkImage current snapshot: true andQuit: true. > -Â run the image with a file as argument that contains: > 5 timesRepeat: [Smalltalk garbageCollect]. > SmalltalkImage current snapshot: false andQuit: true. > The problem is in MCMethodDefinition>>shutdown. Saving works, if i change it to: shutDown " WeakArray removeWeakDependent: Definitions." Definitions := nil. Not sure what happens there.. Also, it runs without fix, if i do: WeakArray restartFinalizationProcess. 5 timesRepeat: [Smalltalk garbageCollect]. SmalltalkImage current snapshot: false andQuit: true. > -- Pavel > > > > > > > _______________________________________________ > 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.

Oct. 8, 2010

Re: [Pharo-project] Seaside and KomHttpServer in Pharo 1.2

by Schwab,Wilhelm K

Thanks! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Torsten Bergmann [astares(a)gmx.de] Sent: Friday, October 08, 2010 9:47 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Seaside and KomHttpServer in Pharo 1.2 >What do you do to test your newly converted Seaside apps? Have you >automated it, or is just a matter of trying everything yourself? Since the app itself is in it's current state not very usefull there are no tests as you may expect to test the app itself (beside a few unit tests) Mainly I test if it is possible to load the whole stuff using Monticello: - seaside in its current version - external webbrowser/ffi - the jquerywidgtbox project on the recent Pharo version and then see if it is possible to: - start and open the app in the browser directly from the image (=> FFI and external browser are working) - have it started as a seaside root (=> if something is displayed) - click around Mostly this is enough to see if something is badly broken. So yes, currently it is more a manual test and more oriented towards if Metacello configs fit together. For instance yesterday in Pharo 1.2 the WebBrowser class was deleted and therefore the whole bootstrap process was broken since MetaSource was not loadable via configuration (see the discussion on the pharo list) My idea is to have a simple web app that demonstrates how one can setup various pieces (seaside, jqeurywidgets, metacello, ...) and that is simply installable by a small gofer script. Bye T. -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Igor Stasenko

I recalled one detail: VW Xtreams are composable from the beginning, its a core stream feature. Not like ours, which require wrappers, which i added (and thus a lot of clutter on proxying message sends). :) -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Igor Stasenko

On 8 October 2010 03:14, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: >> Nicolas, >> the design of your version lacks composability. >> Also, i seriously think that read and write streams should not be >> married under same class. >> This could be a paradigm shift for many people, but not for me, since >> i dealt with real-time >> network communications in the past and can say that network >> communication based on bidirectional data flow >> really sucks, because it doesn't scale.. and don't works for more than >> 2 peers :) >> > > I don't see what is not composable. Squeak Xtream is made exclusively > of Xtream wrappers, except some terminal CollectionReadXtream and > future IOHandleReadXtream (not yet existing see below). > Track how the source/destination ivar are defined/used : most > exclusively of other Xtreams. > Also check the messages ~> and <~ for composition. > > I started using Stream wrappers in the 90s for my own applications, > that's not a new idea. > >> By its nature, data flow is unidirectional. Trying to unify things and >> present it as a bidirectional >> leads to bad code, bad usage patterns (see RemoteString) and >> endless discussions around 'do we need a multiple inheritance or not'. >> > > Agree. > I have mostly separated ReadXtream and WriteXtream with one exception, > the so called BufferedReadWriteXtream. > This class was a quick hack and is not satisfying me. > In Squeak, there is one major user of ReadWriteStream: the change log, > so I needed this quick hack. > We can for sure decompose it in two streams, one for read, one for > write, code will be a lot cleaner. > But beware, the two streams will have to share a common state, and > implementation is not straightforward. > > If you look at VW implementation, you will see this kind of object is > a (shared) Buffer and the implementation is quite involved... > But if you want to help with this one, you're welcome. > >> If i want to read from stream, i can do it like following: >> >> file := 'foo.txt' asFile. >> >> reader := file readXStream. >> reader next >> >> if i want to write something, i do >> >> writer := file writeXStream. >> writer nextPut: $x. >> >> and if i need to read & write both, then i probably should tell writer >> and reader >> to share same state, like file handle, cache, buffers etc, but not to >> be the same object. >> so, if i need to write, i should use writer, and if i need to read - i >> should use reader.. >> >> Concerning composability, this is a cornerstone of VW XTreams implementation. >> And after watching their presentation at ESUG, i can say that your >> implementation completely miss the point (sorry). >> Seeing how simple i can build complex parser(s) by composing multiple >> low-level parsers >> in PetitParser, nobody can convince me, that its a bad idea for streams. >> >> Why i can't simply do: >> >> reader := 'aaa.txt' asFile readXStream. >> utf8Reader := UTF8Reader on: reader. >> ? >> > > 1) asFile does not exist yet because I thought it would be much better > to conect to FileSystem > http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar rather than > doing yet another one... it was rather a meta-message, indicating potential intent rather than existing code :) > 2) in the meantime, use an old StandardFileStream (yes I know, not sexy) > 3) compose with message <~ for write and ~> for read > > By now your example shall be translated as > > (StandardFileStream readOnlyFileNamed: Â 'aaa.txt') readXtream buffered > ~> UTF8Decoder. > > Buffering could be automated at FSReadXtream creation. > The utf8 decoder should also be buffered, but it's just a matter of > creating a nice shortCut for composition, maybe simply > > 'aaa.txt' asFile readXtream gunzip utf8. > > Instead of #on:, I implemented #onStream: Â for readXtream wrappers and > #toStream: for writeXtream wrappers. > I concede current implementation is weak because those two messages > are duplicated... > But it's just a matter of gathering the transformers under a generic > subclass as you proposed in Xtream-Wrappers > > Hope it helps, or maybe there are really neat things I missed ? I don't know if there are slides available for XTreams@EGUG talk, but it could give good insights about XTreams design and usage. What i saw there, that it was quite easy to compose streams, without ad-hoc and elaborate messages. But it was so much happening on ESUG, that i don't remember concrete details :) > VW Xtream is really a master piece, reach features, certainly many > hours of development. > Squeak Xtream is a few hours proof of concept. I invite you and every > one interested to complete the work. > Beside, VW Xtream is now MIT, so it's easy to pick any code and unify > if there's a will in this community. > Yes, this is i think would be better to do, so we can share same protocol(s) and behavior among multiple dialects. > Nicolas > >> >> On 8 October 2010 00:51, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/10/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> pay attention that there are two xtreams package frameworks from what I understand >>>> >>>> Â Â Â Â one presented at esug and one developed by nicolas >>>> >>>> Stef >>>> >>> >>> Now, I wonder if I should not rename it SqueaXtream or something - >>> apologize for not being Pharo-tically correct ;) >>> >>> Nicolas >>> >>>> On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote: >>>> >>>>> >>>>> On 06 Oct 2010, at 08:48, Nicolas Cellier wrote: >>>>> >>>>>> See also hijacked Â http://www.squeaksource.com/XTream.html borrowing >>>>>> some of the ideas, but somehow less extreme. >>>>>> Most packages should now load in Pharo. >>>>> >>>>> Hi Nicolas, >>>>> >>>>> I have been looking at the ESUG 2010 slides & google code project pages of xstreams and I must say that I like this very much. >>>>> >>>>> Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with errors that I think are probably fixable. I am browsing it now. >>>>> >>>>> Now my question is, first, do you have some write up somewhere explaining what you did and why, and second, what is the current state of your project and what are your future plans/goals ? >>>>> >>>>> Thx, >>>>> >>>>> Sven >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> 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.

Oct. 8, 2010