- Pharo-users - lists.pharo.org

Re: [Pharo-users] library for comparing semver versions

by Dale Henrichs

The class MetacelloSemanticVersionNumber can be used to compare Semantic version numbers ... Note that there is an outstanding bug that MetacelloSemanticVersionNumber will read improperly formatted version numbers (fix is in the works), so it's not quite as good for validation (at the moment), but it should work for properly formed semantic version numbers ... Dale [1] https://github.com/dalehenrich/metacello-work/issues/392 On 5/27/16 5:21 AM, Peter Uhnak wrote: > Hi, > > is there any library available that can compare versions according to > SemVer? http://semver.org/ > > Thanks, > Peter >

May 27, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Johan Fabry

I think the reason not to change, is not a difficulty in implementation but a design view that is different from yours and mine. And from Sabineâs. And from Stefâs. And maybe from other persons too â¦ Just to say that I think this should have been discussed more. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On May 27, 2016, at 05:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I am wondering. Why people from GT team not do this? I was think it not easy. > > Anyway change following method to remove buttons from top pane: > > "protocol: building actions" > stackDebuggingActionsPragmas > > ^ #( )

May 27, 2016

Re: [Pharo-users] library for comparing semver versions

by Christophe Demarey

Hi Peter, > Le 27 mai 2016 Ã 14:21, Peter Uhnak <i.uhnak(a)gmail.com> a Ã©crit : > > Hi, > > is there any library available that can compare versions according to > SemVer? http://semver.org/ You can check the SemanticVersion class from CargoPackageManager-Minimal at http://smalltalkhub.com/#!/~demarey/CargoPackageManager. The comparison is not fully complete for the suffix part but can be added Christophe

May 27, 2016

library for comparing semver versions

by Peter Uhnak

Hi, is there any library available that can compare versions according to SemVer? http://semver.org/ Thanks, Peter

May 27, 2016

Re: [Pharo-users] Week number from a date

by JuliÃ¡n Maestri

Chalten might help, i remember it had representations for months of years (January of 1990), it might have something similar for weeks. On 13 May 2016 at 05:40, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Yes I agree. We may have a preference to set the week day start (fistDayOfWeek > ?). > > > After that we could agree on the fact the first week is the first complete > week (otherwise it can be a preference). > > Then we need to find the first day index of the first fistDayOfWeek. > (Date year: self year day: 1) weekdayIndex > -> gives the index according to the preference (for now Sunday -> 1) > > Then itâs quite straightforward to get the week number. > > Just have to check if the current date is in the last week of the previous > year (returns 52 or 53). > I did something but not sure yet (but no preference). > > There are been some works on time representation (Chronos if I remember > well ? but cannot load in Pharo 5, depends on OSProcess). > > An interesting read [1]. > > Cheers, > > CÃ©drik > > ps: > http://stephane.ducasse.free.fr/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20… > > > > Interesting to know. But I see this already seems hard coded... > > Date nameOfDay: 1 "--> #Sunday" > > Timespan subclass: #Date > poolDictionaries: 'ChronologyConstants' > > ChronologyConstants class >> initialize > DayNames := #(Sunday Monday Tuesday Wednesday Thursday Friday Saturday). > > Also seems to have changed at some point, with the historical > nameOfDay recorded in the Terse Guide [1] circa 2010 shown to be > different. Perhaps this is something we should make a regional > preference. Was there any ongoing works on other regional > preferences? > >

May 27, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Denis Kudriashov

2016-05-27 2:08 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > codeActionsPragmas > > ^ #( codeDebuggingAction stackDebuggingAction ) > I am wondering. Why people from GT team not do this? I was think it not easy. Anyway change following method to remove buttons from top pane: "protocol: building actions" stackDebuggingActionsPragmas ^ #( )

May 27, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Sabine Manaa

Johan, thank you, this works fine! regards Sabine 2016-05-27 2:33 GMT+02:00 jfabry [via Smalltalk] < ml-node+s1294792n4897659h24(a)n4.nabble.com>: > > I will just leave this here, so that people that prefer the buttons in > their original place can get them back ... > > I did some quick investigating, and itâs straightforward. Just change the > implementation of GTGenericStackDebugger>>codeActionsPragmas to the > following: > > codeActionsPragmas > > ^ #( codeDebuggingAction stackDebuggingAction ) > > Et voila, the stack debugging action buttons now are also available just > above the code pane! > > For extra goodness, the following two-liner is now also going into my > startup preferences, run-once code part: > > GTGenericStackDebugger compile: 'codeActionsPragmas > ^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building > actions' > > Voila, I will never miss those buttons again :-) > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! > Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > > On May 26, 2016, at 11:01, stepharo <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4897659&i=0>> wrote: > > > Yes, and there was also some discussion on the Pharo-users mailing list. > Apparently the same comments more or less ... > > I give a big +1 on moving the buttons down, so that they are between the > stack and the code pane. I still donât understand why they need to be so > far away from the code pane, it makes much more sense above the code pane + > we save on mouse movements. > > > Because doru got trapped into his own view on "UI design". > > Even apple does not respect its own design documents. > > Stef > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897659.… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Pharo Smalltalk Users, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897703.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 27, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Johan Fabry

I will just leave this here, so that people that prefer the buttons in their original place can get them back ... I did some quick investigating, and itâs straightforward. Just change the implementation of GTGenericStackDebugger>>codeActionsPragmas to the following: codeActionsPragmas ^ #( codeDebuggingAction stackDebuggingAction ) Et voila, the stack debugging action buttons now are also available just above the code pane! For extra goodness, the following two-liner is now also going into my startup preferences, run-once code part: GTGenericStackDebugger compile: 'codeActionsPragmas ^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building actions' Voila, I will never miss those buttons again :-) -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On May 26, 2016, at 11:01, stepharo <stepharo(a)free.fr> wrote: > > >> Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ... >> >> I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still donât understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements. > > Because doru got trapped into his own view on "UI design". > > Even apple does not respect its own design documents. > > Stef

May 27, 2016

Re: [Pharo-users] Having STON generate flatter output

by Sven Van Caekenberghe

Yes, STON uses depth-first traversal of the object graph. Since it uses numbered references, the traversal has to be fixed. This excludes other traversals, as far as I can see. > On 26 May 2016, at 22:00, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following. > So maybe the strategy could be to follow BFS and use subinstances of Collection as references. > > Peter > > On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot: > > <ffcheafc..png> > > [1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212 > > I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution. > > Cheers, > > Offray > > > On 26/05/16 13:52, Peter UhnÃ¡k wrote: >> Hi, >> >> is it possible to configure STON to generate more flat output? >> >> Imagine a scenario where an element can have children and the children have reference to their parent >> >> <Mail Attachment.png> >> â >> Now the problem is that the output of STON will depend on the order of the items, >> so if I have "nice" ordering for the following, I will get a flat output >> >> <Mail Attachment.png> >> â >> If however the ordering is different, the output will be more nested >> >> <Mail Attachment.png> >> â >> As the ordering is not stable, I often end up with results like this (zoomed out) >> >> <Mail Attachment.png> >> â >> The image above has depth of about fourteen, even though it could be represented with just depth of four. >> >> In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs. >> >> So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels. >> >> Thanks, >> Peter >> > >

May 26, 2016

Re: [Pharo-users] Having STON generate flatter output

by Peter UhnÃ¡k

At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following. So maybe the strategy could be to follow BFS and use subinstances of Collection as references. Peter On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > I didn't find that strategy and finally created a #flatten method before > serializing my grafoscopio trees, with just what I wanted. At [1] you can > find the last version of the notebook show at this screenshot: > > > > [1] > http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212 > > I know is this doesn't solve in anyway your problem... but may be it could > inspire you in some way. I was asking also for a flatter STON and the idea > of a method to flatten the tree wrote by myself was not evident at the > beginning, but was a very good solution. > > Cheers, > > Offray > > > On 26/05/16 13:52, Peter UhnÃ¡k wrote: > > Hi, > > is it possible to configure STON to generate more flat output? > > Imagine a scenario where an element can have children and the children > have reference to their parent > > > â > Now the problem is that the output of STON will depend on the order of the > items, > so if I have "nice" ordering for the following, I will get a flat output > > > â > If however the ordering is different, the output will be more nested > > > â > As the ordering is not stable, I often end up with results like this > (zoomed out) > > > â > The image above has depth of about fourteen, even though it could be > represented with just depth of four. > > In the current state I cannot actually look at the generated output > because it's impossible to find anything, which is problematic when an > error occurs. > > So the question is if it is possible to push the actual objects as far up > as possible, and use references "@12" only on the deeper levels. > > Thanks, > Peter > > >

May 26, 2016