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

[Pharo-project] Moment of fun

by StÃ©phane Ducasse

Hi guys I would like to build a small lectures based on all the small little crazy expressions that we use like StandardWindow allInstances do: #close. or myObject pointersTo or anObject become: String new. Do you have some cool expressions to share with me. Stef

April 30, 2013

Re: [Pharo-project] dynamic spec contents

by ClÃ©ment Bera

Yeah it would be nice. We wanted to avoid stuff as "primitiveChangeClassTo:". It is nice we can avoid them with Spec. Btw the new inspectors are quite stable so Pharo 3.0 should have soon Spec inspectors by default. 2013/4/30 stephane ducasse <stephane.ducasse(a)free.fr> > ben > > we should add that to the spec chapter. > Can you log it somewhere and one day :) we pair write it :). > > Stef > > On Apr 30, 2013, at 4:20 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > I just added two new examples in Spec-Examples-PolyWidgets ( > https://pharo.fogbugz.com/default.asp?10458) > > It should be soon in Pharo ^^ > > Ben > > On Apr 30, 2013, at 2:27 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > Clement and I are working on the new Inspectors/Debuggers and we would > like yo > dynamically change spec widgets on the fly. > > Is there an example of that somewhere? > > > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 30, 2013

Re: [Pharo-project] Pharo 3.0: how to always use new debugger

by ClÃ©ment Bera

There is currently no way to do this. There is a good reason for that, the new debugger has got inspectors only since yesterday, so it was hardly usable before. Today I peer programmed all day long with Camillo on the new inspectors, based on Spec and a new model, and we are about to have something stable and nice. In a few days we will integrate it and then there will be still some details to clean with the new spec debugger (in the old inspector, inspect: used primitiveChangeClassTo: for the debugger, we want to avoid it for example). At this point, which will be before the end of this Pharo 3.0 iteration (so within a month), we may add an option to open directly full debugger with the new debugger. "Is it desirable ?" The new debugger is much better in term of design and internal implementation. It means for example that anyone can look at it and understand the code, or create its own debugger subclass for its project. It is also easy to maintain and remove a dependency to CodeHolder (the old debugger depends on it). But basically in term of user interaction, it is the same as the old one, except that it now lacks of some features, like inspectors or the context menu in the stack list. On the other hand, one day, when we will add the object centric debugging tool, we will be able to do it with this new debugger, whereas it would have been very hard with the old one. And this is a nice feature for day to day development and end users. 2013/4/30 Damien Cassou <damien.cassou(a)gmail.com> > Is there a way to always use the new debugger, even if "Directly open the > full debugger" is enabled? > > Is it desirable? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing > enthusiasm." > Winston Churchill > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 30, 2013

Re: [Pharo-project] Pharo 3.0: how to always use new debugger

by Camillo Bruni

On 2013-04-30, at 16:40, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Is there a way to always use the new debugger, even if "Directly open the > full debugger" is enabled? > > Is it desirable? we can add a setting for as long as it is in development mode and then once the old one is gone remove the setting again.

April 30, 2013

[Pharo-project] CI link to matching VM

by Ben Coman

not sure if this is a broader question than just Moose CI, so I'm posting here.... I just downloaded latest Moose image from [1] and want to download the matching VM used for the CI testing, but its not obvious which one. Could maybe a VM link be added to the page as artifact, upstream project or permalink ? Or am I missing something ? [1] https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ cheers -ben <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/>

April 30, 2013

[Pharo-project] 512 MB is not that much (Windows limit) WAS: RE: Opal Decompiler status

by Miloslav.Raus＠cuzk.cz

> But we are in 2013 and if we have one thing than it's memory. I wouldn't oppose to having the sources (or the AST or whatever ;-) in [object-]memory, although retaining the option of _also_ still writing all the changes into an external changelog (in case of VM, or the less rare case, Windows crashes). But no, we don't have "enough memory" (although now is perhaps the time to announce that "64GB ought to be enough for anybody" ;-))). > (the $25 Raspi comes with 256MB, the $35 with 512MB.) Incidentally, ~512 MB is the max you can get on Windows (otherwise crash after an ugly ~ 30 sec freeze; I checked sometime around the 2.0 release), and this is not enough for some applications. The Moose people complained a few years back (unable to, on Windows, load a large but otherwise fine image saved on Mac), the only solution offered was "change a #DEFINE or makefile or something like that and rebuild the VM, then pray it works". Currently I avoid using Pharo in case I even suspect the app might come anywhere near that limit (to avoid nasty surprises / hasty rewrites later). Only problems I've heard of concerning DLL's mapped at "weird" offsets in address space (this was cited as reason for the memory limit) were related to trojan horses / stealth viruses tampering with system, and anti-virus / anti-malware SW doing basically the same ;-))) Or something getting loaded really early, geting the DLL - in this case it was kernel.dll - mapped at unusual offset which then got re-used for all other applications, but this was mentioned in context where in the end they were unable to allocate sufficiently large block of contiguous memory because something was siting in the middle of address space - and i _think_ think it was concerning LuaJIT. Would it be possible to prod Jenkins to produce (additional) windows builds with the limit lifted (or set to 2 GB; optionally perhaps a 1GB build) ? So interested testers could try them - as the problem was reported as only manifesting on some comps., while others ran completely fine. I think somebody mentioned that thanks to Jenkins it is/will be a childs play to add/clone another build(s). IMO it would be great to do some larger-scale testing whether this problem still manifests itself and if so whether it could be worked around, or traced to whatever fucks windows up so they load DLL into the middle of the address space ... And lot more people would participate if "build your own VM" would be an optional step (I know, it's not that hard, and setting up mingw or msvc is not that hard either, but it takes a few hours to get it all up & running). I've "played with" (used to solve actual problems / write applications which are used in production, i just got to choose the language ...) a LOT of prog. langs, and I don't remember this problem mentioned elsewhere. For example SBCL, Smalltalk/X, Factor, SWI Prolog, Haskell (a few very different - on the inside as much as on the outside - examples) are able to utilise the whole 2GB (if your windows are configured to the standard 2GB/2GB user/kernel space split). Even that abomination that starts with letter J and is touted as The_Only_VM_and_Language is able to utilize ~1.5 GB on a 32bit system. I'd be able & willing to test on XP/32 and Win7/32+64. I can even test on ~300 machines, although there are only a few hardware configurations, and all are installed according to the same template and mainly use the same software and antivirus. So it's probably not nearly as interesting as 30 totally random machines ... Anybody else thinks this sounds like a good idea ? -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Saturday, April 27, 2013 7:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Opal Decompiler status On Apr 27, 2013, at 6:42 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Thanks Marcus. > I'm among the skepticals concerning the AST, but I'd like to be proven wrong, because AST level would certainly simplify things a lot. > My main reserve is that interruption can occur at BC level, so for debugging purpose, what are your plans? > Will you move the PC at some AST node boundary (if it is possible given side effects of some BC)? > For the Debugger, everything stays as it is (until Pharo 4 or so). if you look at it, the current Debugger never decompiles if there is source available. It *compiles* to get -> the mapping BC -> text -> the information how temporary variables in the byte code are actually related to temps in the source. (this is very complex, temps can be e.g. stored on the heap if they are written to in a closure, and when they are just read they have a different offset in each closure they are in. Conversely, some temps in the byte code are used to store the array that hold the variables that are on the heap.) The old compiler recorded mappings while compiling that where encoded. quite complex, at least for my tiny brain. So the new just keeps the AST annotated with all the needed infos, this is much easier to debug (and we do have the memory these days, and as we cache the AST, it's even fast). So the debugger needs the compiler. The decompiler now exists just to make text so that we can call the compiler in the case there is no .sources. The debugger *always* compiles to get the mappings, as soon as there is source code the decompiler will never be used. (and even if the decompiler is used, the compiler is called right after on it's results so one can record the mappings). So if you make sure there is always source-code (or a representation with the right amount of meta data), you don't need the decompiler. So at the start it will be the source code. And yes, this takes memory. But we are in 2013 and if we have one thing than it's memory. (the $25 Raspi comes with 256MB, the $35 with 512MB.). We could have shipped 2.0 with 8MB of useless Monticello meta data and nobody would have even realized it. (like we have now megabytes of fonts in the image.). Yet the source is special. I really wonder why. (And yes, there should be solutions to not need unused data in main memory and solutions to share across multiple images data that is the same. but for all kinds of stuff, not just source code). Marcus

April 30, 2013

[Pharo-project] Fwd: [vwnc] [ANN] DoubleAgents: A Test Double Library for Visualworks

by StÃ©phane Ducasse

Begin forwarded message: > From: Randy Coulman <rcoulman(a)gmail.com> > Subject: [vwnc] [ANN] DoubleAgents: A Test Double Library for Visualworks > Date: April 30, 2013 4:16:50 PM GMT+02:00 > To: VW NC <vwnc(a)cs.uiuc.edu> > > All, > > I have just released DoubleAgents, a library for creating "test doubles" in Visualworks Smalltalk. > > DoubleAgents is available in the Cincom Public Store Repository. A snapshot of the current version is also on GitHub. The Readme file on GitHub includes high-level documentation if you'd like more information before diving in. > > The full release announcement is on my blog, Courageous Software. > > Thanks, > Randy > > -- > Randy Coulman > Email: rcoulman(a)gmail.com > Home: http://randycoulman.com > Twitter: @randycoulman GitHub: randycoulman > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

April 30, 2013

Re: [Pharo-project] dynamic spec contents

by stephane ducasse

ben we should add that to the spec chapter. Can you log it somewhere and one day :) we pair write it :). Stef On Apr 30, 2013, at 4:20 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I just added two new examples in Spec-Examples-PolyWidgets (https://pharo.fogbugz.com/default.asp?10458) > > It should be soon in Pharo ^^ > > Ben > > On Apr 30, 2013, at 2:27 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Clement and I are working on the new Inspectors/Debuggers and we would like yo >> dynamically change spec widgets on the fly. >> >> Is there an example of that somewhere? >

April 30, 2013

Re: [Pharo-project] about Pharo 3.0 :)

by stephane ducasse

imagine soon athens :) Stef On Apr 30, 2013, at 1:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 30 April 2013 07:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I thought that Pharo 20 got a lot of improvements but when I see Pharo 30, it feels like Pharo 30 is already a big step > forward. This is really positive energy. When fernando will arrive we will move some efforts to Morphic > so thanks you all for this cool feeling. > > Stef > > Yes, Opal opened doors for so many improvements... > > -- > Best regards, > Igor Stasenko.

April 30, 2013

Re: [Pharo-project] save as...

by Norbert Hartl

Am 30.04.2013 um 15:35 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-04-30, at 15:24, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Was there a discussion about "save asâ¦" should not increment the image file number? Any links to it or was it by accident. >> >> In my opinion I liked the difference between save = same file name, save asâ¦ = new automatical filename > > I think so too, and that's the current behavior no? > No, when you try "save asâ¦" you get the current image name and clicking on ok tells the file already exists and if you like to overwrite it. Norbert

April 30, 2013