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

Re: [Pharo-project] World menu and preference compatibility

by StÃ©phane Ducasse

yes! and we decided for the builder in the image :) >>> >> Hi Sean, >> you can declare a menu item with a precondition block. >> the menu item is not added to the menu if the precondition is false. >> We have one example in the core. See the precondition in the #'Software update' item. >> >> WorldState class>>systemOn: aBuilder >> <worldMenu> (aBuilder item: #System) >> order: 4.0; >> withSeparatorAfter; >> icon: MenuIcons smallConfigurationIcon; >> with: [ >> (aBuilder item: #'About...') >> order: 0; >> action: [Smalltalk aboutThisSystem]. >> (aBuilder item: #'Software update') >> order: 1; >> precondition: [self showUpdateOptionInWorldMenu]; >> action: [Utilities updateFromServer]; >> help: 'Load latest code updates via the internet'] >> >> Cheers >> Alain > > Comparing Settings to Preference Annotations might gleam at the difference you might expect between menu annotations in Pharo and Squeak. > > In Pharo the method contains a simple annotation with no args, and the method contains code for building a menuitem using the builder passed as argument, > My speculation: If following the existing preference-style, Squeak will probably use an annotation with more args, with the method body containing the actual action. > i.e. Alains example would be written something like: > WorldState class>>aboutMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 0 > label: 'About... '> > Smalltalk aboutThisSystem > > WorldState>>updateFromServertMenuItem > <menuItemIn: #('WorldMenu' 'System') > order: 1 > label: 'About... ' > visible: #showUpdateOptionInWorldMenu > help: 'Load latest code updates via the internet'> > Utilites updateFromServer > > > Both approaches have their pros and cons. > The one in Pharo depends on a builder responding to certain messages, so expanding the API might lead to breakage if you try to load into an old image. > You also have to define new annotation keywords for each menu you want to build this way, . > > The one for Squeak might suffer a risk of needing a large amount of permutations of annotations , depending on which PluggableMenuItemSpec properties you'd want to be able to leave optional. > > In short: In Pharo you have access to the builder in the method, while in Squeak (based on how Preferences annotations work) I'd expect they end up with a builder parsing an annotation instead. > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 27, 2010

Re: [Pharo-project] Condensing Changes File

by Alexandre Bergel

It happened to me yesterday. It never ends. Today I had an error with a peek method. I suggest to remove the condense change for now. Is it ok with you? Cheers, Alexandre On 27 Apr 2010, at 17:34, Mariano Martinez Peck wrote: > > > On Tue, Apr 27, 2010 at 9:55 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Hi! > > Apparently, the change file cannot be condensed in Core 1.1 anymore. > I am the only one to experience this? > > > Which error do you have ? the image seems to freeze at the end of > the progress bar like the attached screenshot ? > > > Mariano, maybe we could remove temporarily the change condensing > from ConfigurationOfPharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > > <Picture 4.png>_______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 27, 2010

Re: [Pharo-project] ConfigurationOfPharo

by Mariano Martinez Peck

On Tue, Apr 27, 2010 at 7:15 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Mariano, > > now he complains about "OmniBrowser-DamineCassou.462" > (which comes from 1.0 of ConfigurationOfAutomaticMethodCategorizer > which loads 1.0 of ConfigurationOfOmniBrowser > which loads OmniBrowser-DamienCassou.462) > > Looks like this conflicts with "OmniBrowser-lr.469" > which is noted in version 1.1.3 of ConfigurationOfOmniBrowser > > Looks like a conflict: > You now use 1.1.3 of ConfigurationOfOmniBrowser, but the > ConfigurationOfAutomaticMethodCategorizer that you use in > ConfigurationOfPharo still points to 1.0 of ConfigurationOfOmniBrowser. > > Yes, but it doesn't matter. In such situation (conflict), Metacello will load the latest version, in this case, 1.1.3. I cannot mantain all configurations. If you think ConfigurationOfAutomaticMethodCategorizer should have 1.1.3 instead of 1.0, just do it. > Lesson learned: take care when you edit configs since you may break other > peoples code. > I do take care, but I cannot test all configurations. Even more, when they are not stable releases. In addition, I didn't break anything: OmniBrowser-DamienCassou.462 existed at the point I did the configuration. Now, if I browse the repository http://source.wiresong.ca/ob I don't see it. So, maybe Colin removed that version and put Lukas ones and that's why it is failing. Colin, do you know if this was what happened ? > So I would not call this a reproducable Pharo 1.0 Release ;) > > I don't understand. Pharo 1.0 is completly reproducable. I take a PharoCore 1.0 I avaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-10517') perform: #silently: with: true; perform: #load. And I have the PharoDev 1.0 stable release in perfect state and without any problem. Cheers Mariano > > Just try in a clean 1.0 core image: > > -------------------------- > Gofer new > squeaksource: 'MetaSource'; > package: 'ConfigurationOfMetaSource'; > load. > > ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.0-alpha1') > load > -------------------------- > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 27, 2010

Re: [Pharo-project] Condensing Changes File

by Mariano Martinez Peck

On Tue, Apr 27, 2010 at 9:55 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi! > > Apparently, the change file cannot be condensed in Core 1.1 anymore. I am > the only one to experience this? > > Which error do you have ? the image seems to freeze at the end of the progress bar like the attached screenshot ? > Mariano, maybe we could remove temporarily the change condensing from > ConfigurationOfPharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

April 27, 2010

Re: [Pharo-project] FFI in 1.1

by Igor Stasenko

On 28 April 2010 00:14, Bryce Kampjes <bryce(a)kampjes.demon.co.uk> wrote: > On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: >> On 26 April 2010 10:57, Lukas Renggli <renggli(a)gmail.com> wrote: >> > Igor, >> > >> > Looks cool, but I really would like to know the exact difference to Exupery? >> > >> > For what I understand NativeBoost is no different to Exupery's >> > low-level code generation infrastructure. >> >> You are free to use any code generator you want. NativeBoost plugin is >> really dumb and will run your code at your will. >> I am using AsmJit, because its small and dumb too. Mainly its just an >> x86/x64 instruction database with >> some convenience class(es) and methods to generate instructions directly. >> In contrast, Exupery is a full-blown compiler, but supports a very >> small subset of x86 instructions. >> Actually, i think that with some effort, an Exupery could use AsmJit as backend. >> Not sure, if Bryce likes this idea :) >> > > It sounds like NativeBoost is rather similar to Exupery's lower levels. > Exupery can replace individual methods with native code. > > Exupery's design supports the easy removal of all native code which is > necessary when saving the image if it might be loaded on a platform or > by a VM which can not run x86 machine code. > NativeBoost does it a bit differently. Each piece of native code having a special marker - platform id, which is checked before entering native code. If native code platform id matching the platform id of currently running VM, then native code is allowed to run, and if not, then primitive are just failing, refusing to run it. In this way, a native code can be saved in image, but having no chances to run on a wrong target platform. > The VM hooks are rather small and the code generator is reasonably small > and simple. Exploring multiple approaches may be more valuable than > saving a small amount of duplicate effort. > > Bryce > > > _______________________________________________ > 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.

April 27, 2010

Re: [Pharo-project] NSAbstractDataStream class >>initialize

by Mariano Martinez Peck

On Tue, Apr 27, 2010 at 9:30 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Damien, > > The method NSAbstractDataStream class >>initialize contains the following > code: > -=-=-=-=-=-=-=-=-= > Smalltalk do: [:cls | > cls isInMemory ifTrue: [ > cls isBehavior ifTrue: [ > cls isPointers not & cls isVariable & cls > isWords ifTrue: [ > (t includesKey: cls) ifFalse: [t at: > cls put: 20]]]]]. > -=-=-=-=-=-=-=-=-= > > The problem is that isInMemory is not in Pharo 1.1 anymore. > I think that you can remove the condition "cls isInMemory ifTrue: [". Maybe > someone else can confirm? > > Yes, it can be removed. However, what happens if someone wants that in Pharo 1.0 ? Anyway, that code of isInMemory was for ImageSegment...I don't think it is very used. > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

April 27, 2010

Re: [Pharo-project] FFI in 1.1

by Bryce Kampjes

On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: > On 26 April 2010 10:57, Lukas Renggli <renggli(a)gmail.com> wrote: > > Igor, > > > > Looks cool, but I really would like to know the exact difference to Exupery? > > > > For what I understand NativeBoost is no different to Exupery's > > low-level code generation infrastructure. > > You are free to use any code generator you want. NativeBoost plugin is > really dumb and will run your code at your will. > I am using AsmJit, because its small and dumb too. Mainly its just an > x86/x64 instruction database with > some convenience class(es) and methods to generate instructions directly. > In contrast, Exupery is a full-blown compiler, but supports a very > small subset of x86 instructions. > Actually, i think that with some effort, an Exupery could use AsmJit as backend. > Not sure, if Bryce likes this idea :) > It sounds like NativeBoost is rather similar to Exupery's lower levels. Exupery can replace individual methods with native code. Exupery's design supports the easy removal of all native code which is necessary when saving the image if it might be loaded on a platform or by a VM which can not run x86 machine code. The VM hooks are rather small and the code generator is reasonably small and simple. Exploring multiple approaches may be more valuable than saving a small amount of duplicate effort. Bryce

April 27, 2010

Re: [Pharo-project] Getting Pharo 1.1 from PharoCore 1.1

by Mariano Martinez Peck

On Tue, Apr 27, 2010 at 9:36 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Mariano, the method unregisterOpenCommand: does not exist in 1.1. The > method > DEVImageCreator>>cleanOpenMenu raises a DNU. DEVImageCreator is used to > produce Pharo. > Thanks Alexandre. I have just reproduce it. I don't know which is the intended solution. The problem is that TheWorldMenu is empty, no methods. Even more, it will removed. So...how we should fix all the places where TheWorldMenu was used ? I don't know. If someone know, please feel free to fix it and commit it. > > Cheers, > Alexandre > > NB: Shall I send these email as private or is it okay on the mailing list? > Is there anyone working on packaging Pharo 1.1? > > Send to the mailing list. I don't have too much time these days. So I guess you (and the rest of the people) should continue to push this. Cheers Mariano > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 27, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

On Tue, Apr 27, 2010 at 7:32 PM, Tim Mackinnon <tamackinnon(a)gmail.com>wrote: > Hi Mariano - I see that you have been working on Algernon - I haven't use > Pharo that much (not Squeak to be honest - but I remember trying one of > Damien's dev images that had Algernon and I thought it was pretty cool, and > quite helpful for getting up to speed with Pharo). > > Me too. That's why I suggested to include it again in PharoDev 1.1 when this is done. > Anyway - I am not sure how to get it running? Do I need a 1.1 image > > - or will it work in 1.0? > I don't know 1.1. For the moment I use 1.0 > Do I load the ConfigurationOfAlgernon - and then should it work? > yes, try: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAlgernon'; load. ((Smalltalk at: #ConfigurationOfAlgernon) project version: '0.9.1') load does it work ? > When I do this - Shift-Return doesn't work (nor control-space). If I browse > monticello for just Algnernon, I see there is a later version of Algernon, > but if I load that I seem to get a walkback about a hand not understanding > something. > > Do you have any tips to get me going? And is it possible to update the > Squeaksource text to help newbies like me get going? > > At some point, the welcome workspace was opened once after installing it. I don't know why it dissapear. Should we put it again ? Evaliuate 'Algernon openWelcomeWorkspace' Cheers mariano > Tim > > On 16 Jan 2010, at 23:16, Mariano Martinez Peck wrote: > > > > On Sat, Jan 16, 2010 at 10:48 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > >> Hi Mariano, >> >> From a cursory look, it seems that it would be enough. I'll try to find >> some time next week to make a version that works using this infrastructure. >> >> > Cool !! Let me know so that we can integrate this change in PharoCore and > ask other people for the impact it can bring. I am not sure about that. Do > you know? > > > Cheers, >> Romain >> >> >> On Jan 16, 2010, at 11:43 AM, Mariano Martinez Peck wrote: >> >> Hi guys: Of course I would like having keymapper or similar working in >> Pharo, but as I always say, I rather go step by step. >> >> Last night, I was up to 2 am trying to get this working. I was almost >> there, but as I don't know everything about Morphic, I ask to you. >> >> What Simon said about the binary changeset of Algernon, is true. However, >> I took the time to analyze the changeset and from my point of view (nil >> knowledge in Morphic) it seemed a very good change. I fix it (it has >> underscore assignment) and I was easily merged to Pharo. No conflicts. The >> main change does the simplest modifications to HandMorph for it to support >> various focus holders. And I think this is cool. >> >> So, suppose we integrate this changeset, Algernon, wouldn't have any >> override the method sendKeyboardEvent: >> >> Now Romain, do you think that you can manage to get WorkingSet working >> with this change without overriding? Algernon does, so maybe we can see how >> it do it. I saw this: Algernon >> registerWithSystem >> >> There you will see it does a self activeHand addAdditionalKeyboardFocus: >> self. >> >> That method was part of the Morphic changes. >> >> I commit the Mprhic changes in http://www.squeaksource.com/MarianoPhD >> >> Name: Morphic-MarianoMartinezPeck.396 >> Author: MarianoMartinezPeck >> Time: 16 January 2010, 3:42:18 pm >> UUID: 3587e1b2-36b4-4751-bcdb-ca6f4073788e >> Ancestors: Morphic-MarianoMartinezPeck.395 >> >> Romain, can you take a look and if this is not enough, how can we solve >> easily this problem in Pharo? >> >> Thanks >> >> Mariano >> >> 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> >> >>> >>> On 15 janv. 2010, at 23:03, Mariano Martinez Peck wrote: >>> >>> >>> >>> 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> >>> >>>> >>>> On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: >>>> >>>> >>>> >>>> On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com >>>> > wrote: >>>> >>>>> yes it has overrides ... >>>>> >>>>> that's because as far as I know, there's no keyboard shortcut >>>>> management facility >>>>> in Pharo. If there was one, I suppose Algernon and WorkingSet would >>>>> coexist. >>>>> >>>> >>>> >>>> So...all your overrides are due to the shortcuts? I think it is not >>>> fear to "forbid" a package to be included in a Dev image if we don't provide >>>> from the core a way to manage shortcuts. So: >>>> >>>> 1) Or we let this projects to be installed in the Dev image >>>> >>>> 2) We fix the problem with the shortcuts. >>>> >>>> Romain: can you tell us where exactly the problem is ? maybe someone can >>>> give you a hand. >>>> >>>> >>>> >>>> Taking a look at that, there are 2 overrides in WorkingSet >>>> >>> >>> >>> How did you detect that ? >>> >>> >>> >>> Manually, using an extension-aware browser (O2Package, MC browse package, >>> or the package environment) to detect extensions, then check history in the >>> versions browser. >>> >>> >>> >>> Impressive. You should be a detective :) >>> >>> >>> >>> A few years ago, I was called the human debugger during a project :) Now >>> I try to restrain from this kind of sessions though, it's time consuming. >>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

April 27, 2010

Re: [Pharo-project] I would like to have this kind of tool in pharo

by Igor Stasenko

On a second thought, viewing classes like Object in a single flat view will not be so fun :) -- Best regards, Igor Stasenko AKA sig.

April 27, 2010