November 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Package-pane (or 6-paned) browser for Pharo?

by Stephen Travis Pope

Hello all, I'm just moving to pharo, and wanted to port the "package-pane browser" that I originally wrote for Smalltalk-80 and then ported to Squeak. The squeak code obviously doesn't run in pharo, and I wanted to ask whether anyone had already ported it (or something like it). Basically, the tool is just like the standard system browser, except that it parses the class category names into a 2-level hierarchy, making the top-level list much smaller and more manageable (see the screen shot below). Does this already exist? ...any reply appreciated... stp -- Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com

Nov. 15, 2012

Re: [Pharo-project] Crash dump report

by Sebastian Sastre

can't say anything about jit but, for what is worth, it's flawlessly up since we started using the StackVM sebastian o/ On Nov 13, 2012, at 8:11 AM, Esteban Lorenzano wrote: > is the same smalltalk code with same primitives, but not same vm. > I have spotten this problem time to time, and I have the feeling of being something related to the JIT (that's why my first suggestion to Sebastian was to use the StackVM). Most probably: some optimization flags behaves slightly different in different platforms and then some operations made by the jitter ends trying to access invalid memory segments. > > but as I said, is just a "feeling", since is really hard to catch and I don't have real proof (besides the "indirect one": it works fine if we took off the jit). > > Esteban > > On Nov 13, 2012, at 11:00 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> These situations are very hard to debug by outsiders, for the community to help we need a reproduceable case that does not depend on internal or private services. >> >> The stacktrace is not exceptional as far as I can see: it is trying to read a response until EOF, after a POST. >> >> It is quite strange that it would work with the stack VM, since the same Smalltalk code is then running, using the same primitives. Maybe the other VM just postpones/changes the way it fails. >> >> Running out of semaphores is a resource management problem, caused directly or indirectly from certain usage patterns. Again, see the first sentence. >> >> I would advice running units and/or stress tests on the server or on a Linux VM with UI on your Mac. >> >> Bughunts are never easyâ¦ >> >> On 13 Nov 2012, at 00:33, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> yeah the dumps are really strange.. >>> seems like most of the times crashing at this point: >>> >>> 0xffc05bd8 M ZnChunkedReadStream>next -613198972: a(n) ZnChunkedReadStream >>> 0xffc05bfc M ZnUTF8Encoder>nextFromStream: -613185216: a(n) ZnUTF8Encoder >>> 0xffc05c30 M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) >>> ZnStringEntity >>> 0xffc1333c M BlockClosure>on:do: -613184868: a(n) BlockClosure >>> 0xffc1336c M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) >>> ZnStringEntity >>> 0xffc1338c M String class(SequenceableCollection >>> class)>new:streamContents: -679940384: a(n) String class >>> 0xffc133ac M String class(SequenceableCollection >>> class)>streamContents: -679940384: a(n) String class >>> 0xffc133d8 M ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity >>> 0xffc133f4 M ZnStringEntity>readFrom: -613186408: a(n) ZnStringEntity >>> 0xffc13414 M ZnEntity class>readFrom:usingType:andLength: -678925448: >>> a(n) ZnEntity class >>> 0xffc13440 M ZnEntityReader>readFrom:usingType:andLength: -613217204: >>> a(n) ZnEntityReader >>> 0xffc13474 M ZnEntityReader>readEntityFromStream -613217204: a(n) ZnEntityReader >>> 0xffc13490 M ZnEntityReader>readEntity -613217204: a(n) ZnEntityReader >>> 0xffc134ac M ZnResponse(ZnMessage)>readEntityFrom: -614400344: a(n) ZnResponse >>> 0xffc134c8 M ZnResponse>readEntityFrom: -614400344: a(n) ZnResponse >>> >>> On 12 November 2012 16:12, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>>> Hi guys, >>>> >>>> I'm sorry for this news. >>>> >>>> We have a web app that's is increasingly crashing in production (on linux). >>>> >>>> In development (OS X) we couldn't reproduce >>>> >>>> We are falling back to the StackVM >>>> >>>> Here is some dump data we could get >>>> >>>> sebastian >>>> >>>> o/ >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> >> > >

Nov. 15, 2012

Re: [Pharo-project] method wrappers package name problem

by Frank Shearar

On 15 November 2012 17:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We have a little problem with MethodWrappers. Currently, the package is called MethodWrappers4.2 which completely messes up Monticello in Pharo 1.4. > > So, we (me and Stef) would like to rename it to MethodWrappers42, but for that we need access to the repository. Marcus, could you provide this access? There's also http://www.squeaksource.com/ObjectsAsMethodsWrap.html What are the differences between the two? (I've used the latter, and one flaw I quickly found is that it doesn't (but it's easy to add) allow multiple wrappers around the same CompiledMethod. I have some updates lying around on http://ss3.gemstone.com/ss/Scratchpad-fbs/) frank

Nov. 15, 2012

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by H. Hirzel

P.S. I remember that speed might be a problem. When you first open the help system the compilation from markdown is going on with a noticeable delay. On 11/15/12, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Torsten, > > In August this year I loaded NBHelp into Squeak. NBHelp uses the > mark-down syntax. > > Here is a description how I did it > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165587.h… > > (written in markdown :-) ) > > > NBHelp uses PetitParser. > > > You write that you want to have a pluggable design. For a start I > think a dependency on PetitParser would not be harmful though the > code would be larger. But PetitParser is not all that big either. It > helps you to get into action quickly and safely. > > Later on somebody might want to replace it with a manually written > mark down parser. I think there is one in Lukas's wiki code. This then > would make the help system self-contained and a bit smaller. > > As I am concerned I would not have a problem with a dependency on > PetitParser. > > As of now the challenge with the help system is more on the actual > writing of documentation and not so much on the tool side. > > But your work is instrumental to make this happen. Thank you. > > > --Hannes > > On 11/14/12, Torsten Bergmann <astares(a)gmx.de> wrote: >> It should be a pluggable design similar to current help >> system so one can write in wikistyle, html, markdown, ... >> >> But we need one default. I like Markdown too - but >> do we have some lean code to parse or just transform >> it to HTML. >> >> The help system should be relative small - so it >> can be delivered with the default image. >> Dont know about current dependecies of PetitParser >> and friends. >> >> Bye >> T. >> >> >> >> >> >

Nov. 15, 2012

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by H. Hirzel

Torsten, In August this year I loaded NBHelp into Squeak. NBHelp uses the mark-down syntax. Here is a description how I did it http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165587.h… (written in markdown :-) ) NBHelp uses PetitParser. You write that you want to have a pluggable design. For a start I think a dependency on PetitParser would not be harmful though the code would be larger. But PetitParser is not all that big either. It helps you to get into action quickly and safely. Later on somebody might want to replace it with a manually written mark down parser. I think there is one in Lukas's wiki code. This then would make the help system self-contained and a bit smaller. As I am concerned I would not have a problem with a dependency on PetitParser. As of now the challenge with the help system is more on the actual writing of documentation and not so much on the tool side. But your work is instrumental to make this happen. Thank you. --Hannes On 11/14/12, Torsten Bergmann <astares(a)gmx.de> wrote: > It should be a pluggable design similar to current help > system so one can write in wikistyle, html, markdown, ... > > But we need one default. I like Markdown too - but > do we have some lean code to parse or just transform > it to HTML. > > The help system should be relative small - so it > can be delivered with the default image. > Dont know about current dependecies of PetitParser > and friends. > > Bye > T. > > > > >

Nov. 15, 2012

Re: [Pharo-project] method wrappers package name problem

by Marcus Denker

On Nov 15, 2012, at 2:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We have a little problem with MethodWrappers. Currently, the package is called MethodWrappers4.2 which completely messes up Monticello in Pharo 1.4. > > So, we (me and Stef) would like to rename it to MethodWrappers42, but for that we need access to the repository. Marcus, could you provide this access? > I actually don't know what state MW is in... there are multiple ports using multiple strategies. The 42 one is for Squeak, I think. I added you, after fighting with SqueakSource (Stef I could not find in the list) Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 15, 2012

Re: [Pharo-project] [Pharo-users] [Pharo-consortium] Pharo Association

by Fernando Olivero

Cool! It's great that now we have a way of supporting Pharo. I thought it was a bug, but realized that after signing up, you can login but you wont appear in the members list before you actually pay. Thanks, Fernando On Thu, Nov 15, 2012 at 6:09 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I did and it worked. So, it is safe for everyone else to do it, too :) > > Doru > > > On 15 Nov 2012, at 17:58, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > > On Thu, Nov 15, 2012 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> I see. I tried that just now, but it hangs after I press sign up. > > > > try again :-) > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." > > Winston Churchill > > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > >

Nov. 15, 2012

[Pharo-project] method wrappers package name problem

by Tudor Girba

Hi, We have a little problem with MethodWrappers. Currently, the package is called MethodWrappers4.2 which completely messes up Monticello in Pharo 1.4. So, we (me and Stef) would like to rename it to MethodWrappers42, but for that we need access to the repository. Marcus, could you provide this access? Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Nov. 15, 2012

Re: [Pharo-project] [Pharo-users] [Pharo-consortium] Pharo Association

by Tudor Girba

I did and it worked. So, it is safe for everyone else to do it, too :) Doru On 15 Nov 2012, at 17:58, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Nov 15, 2012 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> I see. I tried that just now, but it hangs after I press sign up. > > try again :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Nov. 15, 2012

Re: [Pharo-project] [Pharo-consortium] Pharo Association

by Damien Cassou

On Thu, Nov 15, 2012 at 4:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I see. I tried that just now, but it hangs after I press sign up. try again :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 15, 2012