January 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] if Pharo is key for you

by stepharo

In which format? I will put them on a dropbox folder and send them to you. If I forget, please reminded it to me. Stef Le 12/1/15 00:05, Offray Vladimir Luna CÃ¡rdenas a Ã©crit : > Hi, > > Yep, would be nice to have that slides to add to my open Zotero > collection about Pharo/Smalltalk > > [1] > https://www.zotero.org/groups/diseo_y_creacion_phd_msc_universidad_de_calda… > > Cheers, > > Offray > > > > El 11/01/15 a las 15:05, stepharo escribiÃ³: >> super! >> It is always good to do retrospective analysis to see what we learned >> and it looks like you learned a lot. >> If you need pharo slides let me know. >> >> Stef >> Le 11/1/15 17:21, Offray Vladimir Luna CÃ¡rdenas a Ã©crit : >>> Hi all, >>> >>> Just picking up some old threads, so I answer this below. >>> >>> El 18/09/13 a las 01:19, StÃ©phane Ducasse escribiÃ³: >>>> Hi guys >>>> >>>> if Pharo is key for you then you should ask yourself what you did for >>>> Pharo recently. >>>> Writing code, writing documentation helping closing bug entries, >>>> participating to the association, to the consortium... >>>> >>>> Pharo is not happening from spontaneous generation. >>>> >>>> Stef >>>> >>> >>> Well I recently (previous semester) start to: >>> >>> 1. Learn Pharo. >>> 2. Develop my own app to learn and write about the process [a][b]. I >>> will be payed for this prototype and will be a paying member of the >>> association. >>> 3. Made my local group of Pharo/Smalltalk on Data narratives and >>> visualization for Open/Garage/Citizen Science & Research at our local >>> hackerspace with several (3 or 4) meetings that will continue this >>> year [c]. >>> 4. Read a lot of previous email to be aware the community memory and >>> revive older threads when is possible and trying to be a more >>> proactive/visible member of this community, even in my newbie >>> condition. >>> >>> So, what I'm planing for this year: >>> >>> 1. To learn/teach more about Pharo specially moldable tools, fluid >>> interfaces and good devel practices. >>> 1. To have a good application with some data narratives and >>> visualization build on it. A good download page, documentation and >>> with clean code instead of the rookie one I have now. >>> 2. To create a stronger local community around data >>> visualization/narratives for Open/Garage/Citizen Sciecen & Research >>> powered by Pharo. >>> 3. To write more. >>> 4. Economical contributions to the community through the association. >>> 5. Hopefully make stronger ties to the international community in >>> South America or Europe by participating in some event or scholarship >>> (this will depend on costs). >>> >>> Thanks for the questions and I will be glad to read other >>> answers/prospective about persons and Pharo, >>> >>> Cheers, >>> >>> Offray >>> >>> Links: >>> ====== >>> >>> [a] >>> http://mutabit.com/deltas/repos.fossil/grafoscopio/doc/tip/Docs/Es/Articulo… >>> >>> >>> >>> [b] http://smalltalkhub.com/#!/~Offray/Grafoscopio/ >>> >>> [c] http://hackbo.co/ >>> >>> >>> >>> >> >> >> > > > >

Jan. 12, 2015

[ANN] Visual Memory profiler

by Alexandre Bergel

Dear Friends and Colleagues, We are happy to announce Memory Profiler, a new profiler for Pharo. This profiler gives a nice output that indicates the memory consumption along the method call graph. Consider the following piece of code: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= (MSP profile: [ Object browse ] onPackagesMatching: 'Nautilus*' ) inspect -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Consider that MSP uses instrumentation, therefore long execution may take really long. The code above takes about 19 seconds on my iMac. It opens a visualization that indicates some interesting fact about memory consumption. For example, the expression âObject browseâ consumes 14 851 kb with instances of the class Point. More than 1M of points are created. Here is the blueprint obtained: https://dl.dropboxusercontent.com/u/31543901/TMP/memoryBlueprintExample.html A description of the visualization is available here: https://dl.dropboxusercontent.com/u/31543901/MyPapers/Infa15a-MemoryProfili… You need to load Spy from the Configuration Browser. Else the following incantation should work: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Gofer it smalltalkhubUser: 'ObjectProfile' project: 'S2py'; configurationOf: 'Spy'; loadDevelopment. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alejandro & Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 12, 2015

Re: [Pharo-users] VALS semester of code

by Martin BÃ¤hr

Excerpts from Martin BÃ¤hr's message of 2015-01-12 04:01:59 +0100: > i am a mentor for FOSSASIA, which is signing up for VALS semester of code: > http://www.semesterofcode.com/ > http://vps2.semesterofcode.com/ > > while discussing potential projects on irc, the suggestion came up that since > squeak and pharo have been participating in the Google summer of code before > through ESUG, you might be interested in the VALS semester of code too. I don't know if anyone from ESUG, squeak and pharo orgs have tried to sign up, but in case they haven't, in the meantime FOSSASIA has been accepted, and since i am mentoring a few smalltalk projects, i would like to invite squeak and pharo developers to join me as mentors, and also offer you to mentor your own projects. my smalltalk projects are here: http://labs.fossasia.org/2015/01/10/smalltalk-search-app.html http://labs.fossasia.org/2015/01/10/smalltalk-file-editor.html Registration for mentors is by invitation, so if you are able to mentor projects please send me an email with details about projects you would like to mentor. We only have a short time to register mentors and list projects, so please reply as soon as you can. The name of the project Describe the project At a minimum, please include the expected outcome of the project, a potential mentor, the skills and/or languages required to complete the project, and a general "difficulty" level. The project should take about 3 months to complete. Please bear in mind that it's better to start with a smaller project that can be extended if your student proves to be capable rather than have an over-ambitious idea which can't be completed in time. The url of this project This could be for example a link to a bug tracker issue or google doc that describes the project idea. Some tags to facilitate searching (Delimited by comma i.e. php, javascript, html) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Jan. 12, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Dale Henrichs

On 1/12/15 1:43 AM, Usman Bhatti wrote: > > > On Sun, Jan 11, 2015 at 7:14 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Usman, > > Well I don't have an official bugfix yet, but if you filein the > attached method and run the following, PetitParser will downgrade > and get loaded correctly (at least it worked for me)...The fist > two statements are intended to replace GTMetacelloPlatform with > MetacelloPharo30Platform and initialize the registry correctly ... > not sure what impact on Moose these changes will have) : > > > MetacelloPharo30Platform initialize. > [ > MetacelloProjectRegistration > resetRegistry; > primeRegistryFromImage ] > on: Warning > do: [ :ex | > Transcript > cr; > show: 'Warning resumed: ' , ex description. > ex resume ]. > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngrade: [:ex :existing :new | > existing projectName = 'PetitParser' > ifTrue: [ > new projectSpec operator: #=. > ex allow ] > ifFalse: [ ex disallow ] ] ; > load. > > > I tried this script as you told but it didn't load the specific > version I was expecting. I had this message printed on Transcript: > > Warning resumed: Warning: Error finding current version of > ConfigurationOfMoose. Probably an invalid specification. > Warning resumed: Warning: Error finding current version of > ConfigurationOfSmallDude. Probably an invalid specification. > Loading 1.0 of ConfigurationOfDummyParser... > Project: PetitParser 1.51 > ...finished 1.0 > > I can wait until you do an official release for this bug fix. In the > meantime, I've created a configOf my own which means I can find > alternate solutions to replace downgrade. I felt that downgrade is yet > a must because one would not like to upgrade all the time. And one > would not like to load packages by hand when configOf is complex. My > configOf works currently but with downgrade available it'll be much > more cleaner. > Ah ... sorry ... I had made one other change and forgot to mention that:( I did rename the version to 1.5.1 both in petitparser and dummy ... Ah well, you are functional and you have certainly helped me, so I appreciate your help ... My first cut at a fix solves the downgrade but introduces other issues, so I still working things out:) Thanks again! Dale

Jan. 12, 2015

Re: [Pharo-users] issue with and/or inlining

by Marcus Denker

> On 12 Jan 2015, at 12:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 12 Jan 2015, at 10:57, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu(a)gmail.com <mailto:emdonahu@gmail.com>> wrote: >>> >>> Hmm, so that works when I annotate my test class, but I probably shouldn't be >>> exporting pragma concerns to my end users. Was your other suggestion about >>> dealing with the warning itself something I could do, or were you referring >>> to a change to pharo itself? >> >> I think we should remove the warning. >> >> https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and… <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and…> >> > This is now in Pharo4 update 40439 > I made another change that removes the checks from all but âifâ inlining: https://pharo.fogbugz.com/f/cases/14716/Remove-all-notify-from-inline-check… <https://pharo.fogbugz.com/f/cases/14716/Remove-all-notify-from-inline-check…> maybe we should even remove it from ifTrue*â¦ there is checks that the blogs have 0 args. (if we remove it it will instead compile a message send and then raise the error at runtime, making ifTrue&co optimisation transparent, too. Marcus

Jan. 12, 2015

Re: [Pharo-users] issue with and/or inlining

by Marcus Denker

> On 12 Jan 2015, at 10:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu(a)gmail.com <mailto:emdonahu@gmail.com>> wrote: >> >> Hmm, so that works when I annotate my test class, but I probably shouldn't be >> exporting pragma concerns to my end users. Was your other suggestion about >> dealing with the warning itself something I could do, or were you referring >> to a change to pharo itself? > > I think we should remove the warning. > > https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and… <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and…> > This is now in Pharo4 update 40439 > But this just solves the problem for the case where the block for and: has an argument. > > When you send and: [] to a non-boolean (your own Boolean), it will nevertheless optimize the contructâ¦ > (but then the #museBeBoolean: magic should take care of it? I think, yes. > YES! 1 and: [ 2 ] â> DNU SmallInteger and: This means that the code ist compiled with inline and:, then executing calls #mustBeBoolean, and we then do ^ self mustBeBooleanInMagic: thisContext sender Which carefully gets the needed code + data, compile a non-optimized code, executes that and returns it. Magic :-) Marcus

Jan. 12, 2015

Re: [Pharo-users] issue with and/or inlining

by Marcus Denker

> On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu(a)gmail.com> wrote: > > Hmm, so that works when I annotate my test class, but I probably shouldn't be > exporting pragma concerns to my end users. Was your other suggestion about > dealing with the warning itself something I could do, or were you referring > to a change to pharo itself? I think we should remove the warning. https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and… <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and…> But this just solves the problem for the case where the block for and: has an argument. When you send and: [] to a non-boolean (your own Boolean), it will nevertheless optimize the contructâ¦ (but then the #museBeBoolean: magic should take care of it? I think, yes. > In case it's relevant, the warning also seems > to cause an issue where I can't deselect a new class in the system browser > and have to re-open the browser. > > Thanks, > Evan > > > > -- > View this message in context: http://forum.world.st/issue-with-and-or-inlining-tp4798622p4798769.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Jan. 12, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Usman Bhatti

On Sun, Jan 11, 2015 at 7:14 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Usman, > > Well I don't have an official bugfix yet, but if you filein the attached > method and run the following, PetitParser will downgrade and get loaded > correctly (at least it worked for me)...The fist two statements are > intended to replace GTMetacelloPlatform with MetacelloPharo30Platform and > initialize the registry correctly ... not sure what impact on Moose these > changes will have) : > > MetacelloPharo30Platform initialize. > [ > MetacelloProjectRegistration > resetRegistry; > primeRegistryFromImage ] > on: Warning > do: [ :ex | > Transcript > cr; > show: 'Warning resumed: ' , ex description. > ex resume ]. > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngrade: [:ex :existing :new | > existing projectName = 'PetitParser' > ifTrue: [ > new projectSpec operator: #=. > ex allow ] > ifFalse: [ ex disallow ] ] ; > load. > I tried this script as you told but it didn't load the specific version I was expecting. I had this message printed on Transcript: Warning resumed: Warning: Error finding current version of ConfigurationOfMoose. Probably an invalid specification. Warning resumed: Warning: Error finding current version of ConfigurationOfSmallDude. Probably an invalid specification. Loading 1.0 of ConfigurationOfDummyParser... Project: PetitParser 1.51 ...finished 1.0 I can wait until you do an official release for this bug fix. In the meantime, I've created a configOf my own which means I can find alternate solutions to replace downgrade. I felt that downgrade is yet a must because one would not like to upgrade all the time. And one would not like to load packages by hand when configOf is complex. My configOf works currently but with downgrade available it'll be much more cleaner. regards, Usman > > The new method will be part of the next Metacello release and has been > tested[1], but I may take a slightly different approach with the official > bugfix. Setting the operator achieves the desired result, but is not quite > how I would like to address the issue. > > HTH, > > Dale > > [1] https://travis-ci.org/dalehenrich/metacello-work/builds/46640819 > > On 1/8/15 12:32 AM, Usman Bhatti wrote: > > > > On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> Usman, >> >> No, I appreciate your patience:) If creating your own configuration works >> for you then that is a good route to go... >> > >> Sharing your image will make it much easier for me to get the bottom of >> this (on my own schedule:), so please send me a link for accessing your >> image and I'll dig into this in more detail when I have time ... >> > > Here is the image. > https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip > > You just need to execute the script in the workspace/playground to > reproduce the problem (i.e. launching the directive to load PP 1.51 and > that not happening). > > >> If you find yourself stuck and needing the `downgrade directive` again, >> I'll bump up the priority ... >> > > I can still wait till next week. If you could have a look by then, it'll > be great. > tx. > Usman > > >> >> >> Dale >> >> >> On 01/07/2015 09:19 AM, Usman Bhatti wrote: >> >> >> >> On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >>> >>> On 1/6/15 7:16 AM, Usman Bhatti wrote: >>> >>> Dale, >>> >>> I couldn't make it work with the upgraded Metacello and the script you >>> provided. >>> >>> Steps I did: >>> >>> 1. Download moose image: >>> https://ci.inria.fr/moose/job/moose-5.0/ >>> >>> 2. Update my Metacello to the 'full' version: >>> Metacello new >>> baseline: 'Metacello'; >>> repository: 'github://dalehenrich/metacello-work:master/repository'; >>> get. >>> Metacello new >>> baseline: 'Metacello'; >>> repository: 'github://dalehenrich/metacello-work:master/repository'; >>> onConflict: [:ex | ex allow]; >>> load >>> >>> 3. File in the ConfigurationOfDummyParser (see the first message in >>> the thread). >>> >>> 4. Run this script to downgrade to PetitParser version 1.51 >>> >>> Metacello new >>> configuration: 'DummyParser'; >>> version: '1.0'; >>> repository: '???'; >>> onDowngradeUseIncoming: #('PetitParser'); >>> load. >>> >>> The desired version is still not loaded, am I missing something here? >>> >>> Good question, I don't have a lot of time today to spend time trying to >>> reproduce your problem, but if you send me a copy of the Transcript >>> produced while doing the load I might be able to spot the problem ... >>> >> >> It looks to me that the downgrade command is not working. Whenever I >> point to the version preceding the one loaded, the packages are not fetched. >> >> I am attaching here two files. >> >> The first (Transcript-PP151) is the output of the transcript as you >> asked. You can see that PetitParser packages as defined by the version 1.51 >> are not fetched. All that is loaded is Glamour because the version 1.51 of >> PetitParser loads the latest packages of Glamour. The load works because it >> is an upgrade from the current version of Glamour which is a stable. >> >> When I saw that only Glamour packages are loaded, I thought of testing >> Glamour downgrade too to see if the problem is specific to PetitParser. You >> can see the result in the second file (Transcript-downgrade-glamour). No >> packages of Glamour are fetched because the configuration tries to >> downgrade it (stable is more recent than 3.0.0 which I try to load). >> >> In my opinion, downgrade is not working as required. If you want I can >> share my image thru dropbox so that you can have a look to see what might >> be wrong. >> >> >>> >>> >>> regards, >>> >>> A question: I always use Metacello with ConfigOf and have never used >>> the scripting API myself or saw it being used elsewhere. >>> Can you provide a link that describes the use cases for both: ConfigOf >>> vs. Scripting API? >>> >>> I've noticed the same thing:) >>> >>> My "elevator pitch" for the script api goes like this: >>> 1. The scripting api maintains a registry of the actual project >>> versions loaded into the image, >>> making #currentVersion obsolete. #currentVersion is bad because it >>> does a calculation of >>> the current version that can be very slow and sometimes completely >>> incorrect. >>> 2. The old api has rules that it follows when loading projects (i.e., >>> newer projects always win) and >>> there is no mechanism for altering those rules. The scripting api >>> provides mechanisms for >>> for bending those rules to fit your needs ... like allowing a >>> downgrade of a project. >>> >>> Part of the reason that people haven't changed has to do with how >>> incredibly difficult it is to change the existing inertia. Another part of >>> it is that I continue to support the old way of doing things, so there is >>> no explicit motivation to change. >>> >>> If you look back 2-3 years in the archives of the Metacello mailing >>> list[1] you should be able to find a number of posts where I make a more >>> detailed cases for the scripting api:) >>> >>> At the end of the day, it isn't important to me to "get people to use >>> the scripting api," as I said, I continue to support using the old api. I >>> figure that when enough people start asking questions about how to "bend >>> the Metacello rules" that folks will begin to use the "new" scripting api:) >>> >> >> So, what I learn is that I am trying to bend the rules of Metacello >> which is a rare use case :). I am thinking of avoiding this downgrading >> altogether by forking to create my own ConfigOf that loads the correct >> versions. Downgrading might be an anti-pattern. >> >> Thank you for your patient so far :) >> >> regards. >> >> >> >>> >>> Dale >>> [1] https://groups.google.com/forum/#!forum/metacello >>> >> >> >> > >

Jan. 12, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Usman Bhatti

On Sat, Jan 10, 2015 at 5:22 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Usman, > > Thanks for supplying the image ... with that I could diagnose the problem. > In the final analysis, the onDowngrade: feature just does not work[1]. I > haven't had a `downgrade` use case in my own work flow, so I did not notice > that it wasn't working and the test cases that I do have are obviously > faulty. > > Along the way, I discovered that in the Moose image, there is a custom > MetacelloPlatform class installed (GTMetacelloPlatform) that is not > compatible with the Scripting API. With that class installed, the scripting > API will not work. I was able to install the proper platform class myself, > but it requires manual intervention ... > I do not know the use case for GTMetacelloPlatform. > > Also, it turns out the PetitParser 1.10 is the version that is installed > and your new version 1.51 is not technically a downgrade ... I think that > the version needs to be named 1.5.1 to be a downgrade ... I changed that as > well and that's when I was able determine that onDowngrade: wasn't > functioning correctly. > Yes, this is something I remarked as well. Thanks for working on this problem. regards, > > Basically, the code said "go ahead and downgrade" but when it came time to > actually load the packages, Metacello went ahead with it's standard > algorithm of only loading newer versions of each package. > > I plan to take a crack at fixing this bug this weekend ... and will let > you when I have a fix. > > Dale > > [1] https://github.com/dalehenrich/metacello-work/issues/317 > > > On 1/8/15 12:32 AM, Usman Bhatti wrote: > > > > On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> Usman, >> >> No, I appreciate your patience:) If creating your own configuration works >> for you then that is a good route to go... >> > >> Sharing your image will make it much easier for me to get the bottom of >> this (on my own schedule:), so please send me a link for accessing your >> image and I'll dig into this in more detail when I have time ... >> > > Here is the image. > https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip > > You just need to execute the script in the workspace/playground to > reproduce the problem (i.e. launching the directive to load PP 1.51 and > that not happening). > > >> If you find yourself stuck and needing the `downgrade directive` again, >> I'll bump up the priority ... >> > > I can still wait till next week. If you could have a look by then, it'll > be great. > tx. > Usman > > >> >> >> Dale >> >> >> On 01/07/2015 09:19 AM, Usman Bhatti wrote: >> >> >> >> On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >>> >>> On 1/6/15 7:16 AM, Usman Bhatti wrote: >>> >>> Dale, >>> >>> I couldn't make it work with the upgraded Metacello and the script you >>> provided. >>> >>> Steps I did: >>> >>> 1. Download moose image: >>> https://ci.inria.fr/moose/job/moose-5.0/ >>> >>> 2. Update my Metacello to the 'full' version: >>> Metacello new >>> baseline: 'Metacello'; >>> repository: 'github://dalehenrich/metacello-work:master/repository'; >>> get. >>> Metacello new >>> baseline: 'Metacello'; >>> repository: 'github://dalehenrich/metacello-work:master/repository'; >>> onConflict: [:ex | ex allow]; >>> load >>> >>> 3. File in the ConfigurationOfDummyParser (see the first message in >>> the thread). >>> >>> 4. Run this script to downgrade to PetitParser version 1.51 >>> >>> Metacello new >>> configuration: 'DummyParser'; >>> version: '1.0'; >>> repository: '???'; >>> onDowngradeUseIncoming: #('PetitParser'); >>> load. >>> >>> The desired version is still not loaded, am I missing something here? >>> >>> Good question, I don't have a lot of time today to spend time trying to >>> reproduce your problem, but if you send me a copy of the Transcript >>> produced while doing the load I might be able to spot the problem ... >>> >> >> It looks to me that the downgrade command is not working. Whenever I >> point to the version preceding the one loaded, the packages are not fetched. >> >> I am attaching here two files. >> >> The first (Transcript-PP151) is the output of the transcript as you >> asked. You can see that PetitParser packages as defined by the version 1.51 >> are not fetched. All that is loaded is Glamour because the version 1.51 of >> PetitParser loads the latest packages of Glamour. The load works because it >> is an upgrade from the current version of Glamour which is a stable. >> >> When I saw that only Glamour packages are loaded, I thought of testing >> Glamour downgrade too to see if the problem is specific to PetitParser. You >> can see the result in the second file (Transcript-downgrade-glamour). No >> packages of Glamour are fetched because the configuration tries to >> downgrade it (stable is more recent than 3.0.0 which I try to load). >> >> In my opinion, downgrade is not working as required. If you want I can >> share my image thru dropbox so that you can have a look to see what might >> be wrong. >> >> >>> >>> >>> regards, >>> >>> A question: I always use Metacello with ConfigOf and have never used >>> the scripting API myself or saw it being used elsewhere. >>> Can you provide a link that describes the use cases for both: ConfigOf >>> vs. Scripting API? >>> >>> I've noticed the same thing:) >>> >>> My "elevator pitch" for the script api goes like this: >>> 1. The scripting api maintains a registry of the actual project >>> versions loaded into the image, >>> making #currentVersion obsolete. #currentVersion is bad because it >>> does a calculation of >>> the current version that can be very slow and sometimes completely >>> incorrect. >>> 2. The old api has rules that it follows when loading projects (i.e., >>> newer projects always win) and >>> there is no mechanism for altering those rules. The scripting api >>> provides mechanisms for >>> for bending those rules to fit your needs ... like allowing a >>> downgrade of a project. >>> >>> Part of the reason that people haven't changed has to do with how >>> incredibly difficult it is to change the existing inertia. Another part of >>> it is that I continue to support the old way of doing things, so there is >>> no explicit motivation to change. >>> >>> If you look back 2-3 years in the archives of the Metacello mailing >>> list[1] you should be able to find a number of posts where I make a more >>> detailed cases for the scripting api:) >>> >>> At the end of the day, it isn't important to me to "get people to use >>> the scripting api," as I said, I continue to support using the old api. I >>> figure that when enough people start asking questions about how to "bend >>> the Metacello rules" that folks will begin to use the "new" scripting api:) >>> >> >> So, what I learn is that I am trying to bend the rules of Metacello >> which is a rare use case :). I am thinking of avoiding this downgrading >> altogether by forking to create my own ConfigOf that loads the correct >> versions. Downgrading might be an anti-pattern. >> >> Thank you for your patient so far :) >> >> regards. >> >> >> >>> >>> Dale >>> [1] https://groups.google.com/forum/#!forum/metacello >>> >> >> >> > >

Jan. 12, 2015

Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0

by Sven Van Caekenberghe

Hi Peter, > On 11 Jan 2015, at 12:47, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > Apologies for the delay in replying. > > Basically, the relative argument can be anything that occurs in a LINK tag > in an HTML document. This can be anything from a file name to a complete > address with only the 'http:' missing. > > I have found a couple of examples in a document from the Wikipedia > 'Wiktionary', where I show in the attached workspace file the absolute > address, the two relative addresses and the effect of combining using Url > class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the > output of the Url class>>#combine:withRelative is the expected result; in > the first case ZnUrl>>#inContextOf: gives the expected result, in the second > it does not. > > The relative address in the second case seems a bit odd (why not include the > 'http:' and make it absolute?), but it actually occurs (quite often in > Wiktionary files at least) and the code needs to be able to deal with it. The problem is that ZnUrl>>#inContextOf: works with 2 parsed URL objects. However, relative URLs are not proper URLs and cannot be parsed nor represented as such. For example, 'foo/bar/readme.txt' and '/foo/bar/readme.txt' are the same. Relative URLs only exist while parsing and must then be resolved. Section 5 of RFC 3968 explains in details how to do that. This will have to be added to ZnUrl or to a helper class, but that will take some time. Luckily there are test cases in the document. Thanks for the feedback. Sven > Hope this helps. > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of > Sven Van Caekenberghe > Sent: 10 January 2015 22:56 > To: Any question about pharo is welcome > Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo > 3 and Moose 5.0 > > Peter, > >> On 10 Jan 2015, at 23:30, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >>> Yes change the code of the Parser not to use old code. >> As I pointed out, the Parser is a large and complex package, and I am >> not the author, so this is easier said than done. It seems a bit odd >> to dismiss code which worked OK in Moose 4.9, but not in Moose 5.0, as >> 'old code.' It is code which has no functional equivalent in the new >> code, as Sven has confirmed. > > Could you explain what arguments were given to the combine and what the > expected output was/should be ? How does it use path merging ? > > Thx, > > Sven > <CombineRelWithAbs.ws>

Jan. 12, 2015