March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Getting a functionning unstable image

by Igor Stasenko

On 22 March 2011 19:26, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/3/22 Igor Stasenko <siguctua(a)gmail.com>: >> On 22 March 2011 13:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Mar 22, 2011, at 1:25 PM, StÃ©phane Ducasse wrote: >>> >>>> +1 >>>> >>>> Now condenses change should work too :) >>>> >>> >>> I am slowly adopting a radical "if we don't test it, it's will brake" point of view. >>> I now even say: If we don't test it, it *should* be broken! Because it is dead >>> code and should be removed. >>> >> >> I like a systematic approach. :) >> > > Agree, > If not maintained it won't work. > If not tested it's not maintained. > So your sentence must be true in most cases (except case of luck) > > And if not maintained, the choices are > - revive > - or remove > and that is the Pharo way, Squeak being more conservative. > It is a realistic approach. Obviously there is not much resources in Pharo task forces to spend them on something which nobody maintains/cares anymore. It is better to focus energy on something that everybody needs and make sure it works well. > Nicolas > -- Best regards, Igor Stasenko AKA sig.

March 22, 2011

[Pharo-project] [update 1.3] #13104

by StÃ©phane Ducasse

13104 ----- - Polymorph override cleaning. Part three Stef

March 22, 2011

Re: [Pharo-project] Issue 2144 in pharo: startUp and shutdown missed registered classes

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 2144 by marcus.d...(a)gmail.com: startUp and shutdown missed registered classes http://code.google.com/p/pharo/issues/detail?id=2144 just checked and I think it looks good (last inspect is empty)

March 22, 2011

[Pharo-project] [update 1.3] #13104

by StÃ©phane Ducasse

13104 ----- - Polymorph override cleaning. Part three

March 22, 2011

[Pharo-project] Issue 3844 in pharo: Utilities is in StartupList

by pharo＠googlecode.com

Status: FixToInclude Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3844 by marcus.d...(a)gmail.com: Utilities is in StartupList http://code.google.com/p/pharo/issues/detail?id=3844 next postscript should do: Smalltalk removeFromStartUpList: Utilities.

March 22, 2011

Re: [Pharo-project] Issue 3701 in pharo: FloatArray>>dot: is defined in plugin but not at the image level

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3701 by marcus.d...(a)gmail.com: FloatArray>>dot: is defined in plugin but not at the image level http://code.google.com/p/pharo/issues/detail?id=3701 cs attached Attachments: FloatArray-dot.st 595 bytes

March 22, 2011

Re: [Pharo-project] Issue 3684 in pharo: primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' returns wrong creation date

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3684 by marcus.d...(a)gmail.com: primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' returns wrong creation date http://code.google.com/p/pharo/issues/detail?id=3684 move to cog tracker http://code.google.com/p/cog/issues/detail?id=12

March 22, 2011

Re: [Pharo-project] [OT] GTK3 directions - what about Morphic ?

by laurent laffont

Little update: http://www.osnews.com/story/24536/Gtk_3_2_Runs_Any_Gtk_Application_in_a_Bro… <http://www.osnews.com/story/24536/Gtk_3_2_Runs_Any_Gtk_Application_in_a_Bro…> Laurent On Wed, Mar 16, 2011 at 11:09 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > Hi, > > I've seen: > - you can style GTK3 with CSS: > http://gnomejournal.org/article/107/styling-gtk-with-css > - GTK3 apps can be rendered in a web browser: > http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ > > This sounds sexy. > > I wonder how hard it would be to have SimpleMorphic go in this direction. > And whether this is useful or not. > > Laurent. >

March 22, 2011

Re: [Pharo-project] Issue 3667 in pharo: ThreadSafeTranscript does not understand crtab and crtab:

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #2 on issue 3667 by marcus.d...(a)gmail.com: ThreadSafeTranscript does not understand crtab and crtab: http://code.google.com/p/pharo/issues/detail?id=3667 fix attached Attachments: FixTranscript.1.cs 406 bytes

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

It's a very simple idea really. Where your bytecode would previously look like pushTemp: 1 pushTemp: 2 add now it looks like: add 1, 2, 3 where 3 is the start of your original stack, for example. So rather than pushing and popping etc, you just abstractly interpret the bytecodes and figure out the stack locations where they would be pushed. And then you use this number as arguments to a copy bytecode, rather than calling "push". This avoids having to maintain a stack where you up front already know what the target index will be. You know this up front since your code is static by itself. The advantage is that you don't need to do stack-tricks to keep data around, since all the operation are simple things such as copy, loadFromOuterScope, storeInOuterScope, loadFromField, storeInField, ... So conversely to what you might have thought beforehand, you don't have "real registers" around, you just consider a stackframe to be a set of registers. And you operate on them with easy bytecodes. The advantage, in addition to it being less work and thus slightly faster by itself, is that it will later on also map better on the real hardware. The operations already look like what normal assembler operations would look like. cheers, Toon On 03/22/2011 07:00 PM, StÃ©phane Ducasse wrote: > Can you explain rapidly register-case byte code? > > Stef > > On Mar 22, 2011, at 4:02 PM, Toon Verwaest wrote: > >> On 03/22/2011 04:52 PM, Alexandre Bergel wrote: >>>>> I am not saying that this is feasible with the current VM. But I am doubtful that the bytecode verification can only be done in the VM. If something get wrong, why not to raise a primitiveFailed, as 1/0 will do? >>>>> >>>> Because checking all these things at runtime will make interpretation slow. >>> But could not it be at compile time? >>> >>> I am not expert in VM. But something that I learnt from all over these years, is that if we copy what other people do, then we will just have a pale copy. Innovation begins by doing what other think it is impossible to do. Smalltalk has classes as object, whereas Java and C++ took a different stance. Smalltalk has the debugger and the profiler in the image; again, java people have a different opinion. Now, if someone say that bytecode verification can only be done in the VM, I am skeptic. >> Ok, I very much understand this point of view. That's exactly why I started Pinocchio. >> >> I'm currently building my 4rd iteration. I started building a Smalltalk by having AST evaluation (actually I started out with self-evaluating AST objects that got evaluated by sending message... :D) . Then moved on to stack-based bytecodes. Then moved on to registered-based bytecodes (where I am now). All of my progress has been made by careful scrutinizing of the problems at hand. I did reevaluate and question all steps; and I'm a bit sad that I ended up doing it this way... But then I guess there is some inevitability in it. >> >> For example the register-based bytecodes, I had no idea that what I was doing were register-based bytecodes until I read the Lua VM description and noticed that it was exactly the same. >> >> However I do think that I learned a lot by doing it. I made the trade-offs myself and understand them a lot better than I did before. What I'm defending in this discussion isn't based on estimates but experience from building it from the ground up. >> >> And this is where I welcome everyone to do the same! It took me 2 years to get to where I am now, but maybe it goes faster for you ;) It is definitely a very worthwhile exercise. And I think because of it I'm finally at the point where I can contribute something... >> >> cheers, >> Toon >> >

March 22, 2011