May 2016 - Pharo-dev - lists.pharo.org

Spec: Rereading Dolphin book and MVP

by stepharo

Hi In MVP the presenter has direct access to the Model and (of course it means that the Model API is fixed) but I wonder if this would not help us simplify Spec. Model <---- presenter <----> View What do you think? Stef

May 14, 2016

Re: [Pharo-dev] Easier way to parse this?

by Tudor Girba

And here it is with PetitParser using the islands support. I think this is the nicest to read: codeParser := ( '<code>' asParser, '</code>' asParser negate star flatten , '</code>' asParser) ==> [ :t | t second asUppercase ]. parser := codeParser island star ==> [: t | '' join: t flatten ]. originalString := 'this is a string with <code>some funny lines</code> and here is another <code>haha</code>'. parser parse: originalString â--> this is a string with SOME FUNNY LINES and here is another HAHA" Cheers, Doru > On May 12, 2016, at 10:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > I always solve such kind of problems with streams. It is super easy and much easy then regex (I hate regex). For your case it would be something like: > > in := source readStream. > result := String streamContents: [:out | > [in atEnd] whileFalse: [ > out nextPutAll: (in upToAll: '<code>'). > code := in upToAll: '</code>'. > out nextPutAll: code asUppercase; nextPutAll: '</code>']. > ] > > And it could be much nicer with Xtreams but I not remember it API (maybe tomorrow I will remember). > > 2016-05-12 21:50 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys, > > I wonder which is the easier way to do the following. I have a string which inside could have something like 'this is a string with <code>some funny lines</code> and here is another <code>haha</code>'. I need to parse that string, get all places where I have things surrounded with <code>SOMETHING</code>, get the "SOMETHING" (in previous example, that would be 'some funny lines'), execute that (this is something internal) , and from that I get the real string (imagine in this case the answer is 'SOME FUNNY LINES'). Finally, I need to replace the orignal string... So ... given the input: > > 'this is a string with <code>some funny lines</code> and here is another <code>haha</code>' > > And given my specific domain logic transformation (in this example I assume a simple #asUppercase), I would like to get: > > 'this is a string with SOME FUNNY LINES and here is another HAHA' > > I got it working with below lines. But it is a hack and terrible slow (I imagine). > So...anyone has an idea how can I do this simpler/faster? Maybe some RB re-write rule? > > Thanks in advance > > > > | dom string originalString stringToBeAbleToParse xmlDocument replacements finalString | > replacements := Dictionary new. > originalString := 'this is a string with <code>some funny lines</code> and here is another <code>haha</code>'. > stringToBeAbleToParse := '<hack>', originalString, '</hack>'. > dom := XMLDOMParser on: stringToBeAbleToParse. > dom configuration isValidating: false. > xmlDocument := dom parseDocument. > (xmlDocument allElementsNamed: 'code') do: [ :aXMLElement | > > "Let's simulate my domain transformation logic as a simple #asUppercase" > replacements at: aXMLElement asString put: (([:code | code asUppercase ]) value: aXMLElement nodes first asString). > ]. > finalString := originalString. > replacements keysAndValuesDo: [ :originalText :new | > finalString := finalString copyReplaceAll: originalText with: new. > ]. > finalString > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

May 14, 2016

Re: [Pharo-dev] About Pragma keyword vs Pragma selector

by Tudor Girba

Hi, I would agree with that. The only thing to take into account is that this can introduce incompatibilities with external libraries, but I do not think this would be much. Cheers, Doru > On May 14, 2016, at 3:03 PM, stepharo <stepharo(a)free.fr> wrote: > > I would rename > > Pragma>>keyword into Pragma>>selector > > Pragma>>selector into Pragma>>methodSelector > so like that it is coherent with > > Message and method api and with Pragma>>methodClass > Le 13/5/16 Ã 14:33, stepharo a Ã©crit : >> Color >> gtInspectorColorIn: composite >> <gtInspectorPresentationOrder: 30> >> >> composite morph >> title: 'Color'; >> display: [ BorderedMorph new color: self ] >> >> pragma := (Color >> #gtInspectorColorIn:) pragmas first >> pragma arguments >> > 30 >> pragma keyword >> > #gtInspectorPresentationOrder: >> >> >> I wonder why pragma returns their selector using keyword and not selector? >> >> Especially since message API uses selector. >> >> >> Pragma >> message >> "Answer the message of the receiving pragma." >> >> ^ Message selector: self keyword arguments: self arguments. >> >> Stef >> >> >> > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

May 14, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

Yes :) > >> On 09 May 2016, at 13:45, Henrik Johansen >> <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> >> wrote: >> >> Yes, IIRC, the whole idea behind Spec was to have a literal syntax >> for specifying UI's. (Which is a neat storage format for, say, a >> UIBuilder) >> The focus seems to have changed over time to directly using what was >> initially the intermediate object model the builder generated when >> parsing the spec. > > btw, Iâve never been happy with that change :) > and I agree, the original idea was to have some s-strings based > description so an UI builder (to be done) could do a better job. > > Esteban > >> >> Cheers, >> Henry >> >>> On 09 May 2016, at 1:22 , Denis Kudriashov <dionisiydk(a)gmail.com >>> <mailto:dionisiydk@gmail.com>> wrote: >>> >>> >>> 2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com >>> <mailto:i.uhnak@gmail.com>>: >>> >>> No. Morphs are created by Adapters, Spec interpreter >>> instantiates glues everything together. >>> Regardless, there's no parsing involvedâ¦ what is there to parse? >>> There are no literal arrays anywhere. >>> The SpecLayout (that we called array last week), is not an >>> array, it's a composition of real objects >>> >>> defaultSpec >>> ^ SpecLayout composed >>> newRow: [ :row | row newColumn: [ :col | col add: #topToolbar >>> height: self toolbarHeight ] ] >>> height: self toolbarHeight; >>> newRow: [ :row | >>> row >>> newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 >>> corner: 0.2 @ 1; >>> addSplitter; >>> newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 >>> corner: 0.85 @ 1; >>> addSplitter; >>> newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 >>> corner: 1 @ 1 ] >>> top: self toolbarHeight; >>> yourself >>> >>> >>> Maybe array approach deprecated? But in first demos of Spec it was >>> like this: >>> >>> CheckBoxExample class>>defaultSpec >>> >>> ^ { #ContainerModel. >>> #add:.{ self topSpec. #layout:. #(#SpecLayoutFrame >>> bottomFraction: 0 >>> bottomOffset: 20) }. >>> #add:.{{#model . #container } . #layout: . #(#SpecLayoutFrame >>> topOffset: 22) } >>> } >>> >>> (Actually it is from Pharo 5 image). >> >

May 14, 2016

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

by Esteban Lorenzano

> On 14 May 2016, at 14:59, stepharo <stepharo(a)free.fr> wrote: > > Hi Jeff > > We discussed two weeks ago so from my memory: > > We should see if we cannot do a 6 months release instead of 12 months. as it is now is just not possible. It took Marcus and me two full weeks of working on boring details and now Iâm fried (and I know Marcus is too)â¦ now, we need to change the process so we can do this easier, then yes we can release more frequently :) > > - git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us > > managing cross projects changes > > - bootstrap pavel, christophe and guille are working on it > > - Cargo package manager christophe should release a version soon > > - Epicea this would means also (probably) changing from once the sources/changes formatâ¦ now changes keeps a delta too and there is an unnecessary overlap with epicea. > > - cleaning tools, cleaning spec, ProtoObject, > > - being able to remove the old compiler and reload it > > - improving the coverage of the core bootstrap > > - removing useless stuff (newList, TextHolder...) > > - Probably 64 bits not just probablyâ¦ this is a strong âmustâ :) also we should not be too far from having it. > > For Bloc it also depends on Brick. yes, most probably we will include block but we would not replace morphic in Pharo 6â¦ is too much work and weâll take some more time for stabilising and moving onto it. other issues: - UFFI 2.0 (optimisations, better support for arrays, etc.) - OSWindows will take over the world :) and I think this is enough for a version :) Esteban > > stef > > >

May 14, 2016

Re: [Pharo-dev] Help on using Git with Pharo

by stepharo

Alexandre I do not understand why you are so negative. May be people are using git from within Pharo. May be your experience was not good. Now Nicolas is working to bring the possibility to publish on gitlike systems inside pharo. I imagine that when it will be ready to try we will know it. Stef Le 8/5/16 Ã 18:29, Alexandre Bergel a Ã©crit : > Hi Peter! > > Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-) > >> The in-image help sucks hardâ¦ monospaced walls of text, no formatting, no styling, no images, and zero discoverability. >> >> Some ideas â this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: > I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example). > > >> ### Simple-ish: online fronted >> ... >> ### Complex-ish >> â¦ > Sure, would be great :-) > >> ## 2. Comments for the git help (I've just skimmed through it briefly) >> >> My impression is that it doesn't really describe git in Pharo, which is what we are pushing forâ¦ >> >> >> it is recommanded to tick the checkbox "Initialize this repository with a README". >> This will ease the initialization of the repository (you will be able to immediately clone your repo). >> >> GitHub is lying, you can clone it regardless > Well.. I am okay living with this lie :-) > >> - From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options) >> >> Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo. > Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly. > >> To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. > The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-) > >> The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. > Yes, that would be great. > >> So my point is: if we want to provide help for people, we should push them in the correct directionâ¦ that is towards git IN pharo. >> If we push them to not actually use git in Pharo, then we will push them away from our objectives. > Yes, but that will take years before getting there. And I need to use it nowâ¦ and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges). > > In any case, I will use this Help for me, and will not try to push it. > Thanks for having a look at it :-) > > Cheers, > Alexandre > > >> >> >> On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> I have written a help to use Git in Pharo. Execute the following: >> >> Metacello new >> baseline: 'GitHelp'; >> repository: 'github://bergel/Git-Help:master'; >> load. >> >> It will load a Help topic, available on the Help Browser. >> If you wish to contribute: >> https://github.com/bergel/Git-Help >> >> One some point, I will propose an inclusion in the base image. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >>

May 14, 2016

Re: [Pharo-dev] About Pragma keyword vs Pragma selector

by stepharo

I would rename Pragma>>keyword into Pragma>>selector Pragma>>selector into Pragma>>methodSelector so like that it is coherent with Message and method api and with Pragma>>methodClass Le 13/5/16 Ã 14:33, stepharo a Ã©crit : > Color >> gtInspectorColorIn: composite > <gtInspectorPresentationOrder: 30> > > composite morph > title: 'Color'; > display: [ BorderedMorph new color: self ] > > pragma := (Color >> #gtInspectorColorIn:) pragmas first > pragma arguments > > 30 > pragma keyword > > #gtInspectorPresentationOrder: > > > I wonder why pragma returns their selector using keyword and not > selector? > > Especially since message API uses selector. > > > Pragma >> message > "Answer the message of the receiving pragma." > > ^ Message selector: self keyword arguments: self arguments. > > Stef > > >

May 14, 2016

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

by stepharo

Hi Jeff We discussed two weeks ago so from my memory: We should see if we cannot do a 6 months release instead of 12 months. - git support and process (nicolas passerini is working on it) the idea is to have a process (not just a command line) that helps us managing cross projects changes - bootstrap pavel, christophe and guille are working on it - Cargo package manager christophe should release a version soon - Epicea - cleaning tools, cleaning spec, ProtoObject, - being able to remove the old compiler and reload it - improving the coverage of the core bootstrap - removing useless stuff (newList, TextHolder...) - Probably 64 bits For Bloc it also depends on Brick. stef

May 14, 2016

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

by Peter UhnÃ¡k

I second Torsten. Even though I had a lot of trouble over the font bug, I'd argue it was more of a problem on my side as I didn't adapt appropriately... after all we still have available all versions of the release. As long as the core devs are ok with the amount of change, I don't see a problem. And if you want to live on the `bleedingEdge`, well then also read the first part of the word. :) So as long as people who create the stuff actually manage it, I'm happy with the bumpy ride because the result is that more amazing. Peter On Fri, May 13, 2016 at 7:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Cyril Ferlicot wrote: > > It would be good to have one to not integrate too many new things like > > in Pharo 5 and have trouble stabilizing it. > > Please define "too many" and "trouble" :P > > Hey - right after Pharo 4 was release I switch and used Pharo 5 through > the whole > development cycle even during the "shaky" times. Following the point > "Communication is key" > in Pharo Zen this was clearly announced to all the contributors. > > Yes - there was some trouble inbetween and yes it costed us all time and > work to switch > also to UFFI and others. But Spur now made us faster, UFFI more unified, > ... > > From my POV Pharo 5 primarily was usable enough even for the ones living > (working) on the edge. > It's anyones own decision to take the unstable ride during development of > next version or stay > with the last stable release. > > As we all know the only constant in life is change: so we should not fear > to change, add > or remove when we see it as necessary. The more new and interesting stuff > the better. > How much "more" really means will be depending on all our contributions > which I hope > will again increase. > > Pharo 6 should and will again be better and I hope it will include many > new stuff > even when things might get shaky again. > > Step by step it goes... > > Bye > T. > >

May 13, 2016

Re: [Pharo-dev] [ANN] Pharo 6.0 Development started

by Torsten Bergmann

Cyril Ferlicot wrote: > It would be good to have one to not integrate too many new things like > in Pharo 5 and have trouble stabilizing it. Please define "too many" and "trouble" :P Hey - right after Pharo 4 was release I switch and used Pharo 5 through the whole development cycle even during the "shaky" times. Following the point "Communication is key" in Pharo Zen this was clearly announced to all the contributors. Yes - there was some trouble inbetween and yes it costed us all time and work to switch also to UFFI and others. But Spur now made us faster, UFFI more unified, ... >From my POV Pharo 5 primarily was usable enough even for the ones living (working) on the edge. It's anyones own decision to take the unstable ride during development of next version or stay with the last stable release. As we all know the only constant in life is change: so we should not fear to change, add or remove when we see it as necessary. The more new and interesting stuff the better. How much "more" really means will be depending on all our contributions which I hope will again increase. Pharo 6 should and will again be better and I hope it will include many new stuff even when things might get shaky again. Step by step it goes... Bye T.

May 13, 2016