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

Re: [Pharo-dev] XMLParser changes

by Peter UhnÃ¡k

I re-read this thread three times and I am confused. Is there a way to just ignore the whitespace? The XML contains doctype (<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" " http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">) so maybe that's why it's broken? But if I understand correctly, the _correct_ way to solve this is not to ignore the whitespace on parse time, but on processing time, correct? Peter On Wed, Apr 27, 2016 at 10:29 AM, Cyril Ferlicot Delbecque < cyril.ferlicot(a)gmail.com> wrote: > > > On 27/04/2016 09:12, stepharo wrote: > > Hi guys > > > > > > I did not understand where are the spaces? > > > > The whitespaces are the line return and tabulation (indent) for the > pretty print. > > > Can you show me? > > > > Stef > > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

May 9, 2016

Re: [Pharo-dev] Bug in NeoCSV?

by Sven Van Caekenberghe

> On 09 May 2016, at 16:29, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Oopsâ¦ Youâre right. > Sorry about that No problem. Actually, many people use ZnEasy because it seems simple, but it can be deceiving (like in this case). If you want the shortest possible code in scripting I would suggest doing it like this: 'http://bit.ly/exampleCSV' asUrl retrieveContents. 'http://zn.stfx.eu/zn/numbers.txt' asUrl retrieveContents. The #retrieveContents message will fail unless there is a proper HTTP 200 OK response. And it is all cool unary messages ! > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On May 9, 2016, at 10:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 09 May 2016, at 15:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Hi Sven, >>> >>> There is apparently a problem in NeoCSVReader. #codepoint is apparently missing >>> The following code raises an exception: >>> >>> urlAsString := 'http://bit.ly/exampleCSV'. >> >> Can you give me a working URL so that I can try myself ? >> >>> content := (ZnEasy get: urlAsString) contents readStream. >>> lines := (NeoCSVReader on: content) >>> skipHeader; >>> upToEnd. >>> >>> >>> I loaded NeoCSV using: >>> Gofer new >>> smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; >>> package: 'ConfigurationOfNeoCSV'; load. >>> (Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge. >>> >>> Any idea? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >> >

May 9, 2016

Re: [Pharo-dev] Bug in NeoCSV?

by Alexandre Bergel

Oopsâ¦ Youâre right. Sorry about that Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 9, 2016, at 10:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 09 May 2016, at 15:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi Sven, >> >> There is apparently a problem in NeoCSVReader. #codepoint is apparently missing >> The following code raises an exception: >> >> urlAsString := 'http://bit.ly/exampleCSV'. > > Can you give me a working URL so that I can try myself ? > >> content := (ZnEasy get: urlAsString) contents readStream. >> lines := (NeoCSVReader on: content) >> skipHeader; >> upToEnd. >> >> >> I loaded NeoCSV using: >> Gofer new >> smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; >> package: 'ConfigurationOfNeoCSV'; load. >> (Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge. >> >> Any idea? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >

May 9, 2016

Re: [Pharo-dev] Bug in NeoCSV?

by Sven Van Caekenberghe

> On 09 May 2016, at 15:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Sven, > > There is apparently a problem in NeoCSVReader. #codepoint is apparently missing > The following code raises an exception: > > urlAsString := 'http://bit.ly/exampleCSV'. Can you give me a working URL so that I can try myself ? > content := (ZnEasy get: urlAsString) contents readStream. > lines := (NeoCSVReader on: content) > skipHeader; > upToEnd. > > > I loaded NeoCSV using: > Gofer new > smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; > package: 'ConfigurationOfNeoCSV'; load. > (Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge. > > Any idea? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

May 9, 2016

Bug in NeoCSV?

by Alexandre Bergel

Hi Sven, There is apparently a problem in NeoCSVReader. #codepoint is apparently missing The following code raises an exception: urlAsString := 'http://bit.ly/exampleCSV'. content := (ZnEasy get: urlAsString) contents readStream. lines := (NeoCSVReader on: content) skipHeader; upToEnd. I loaded NeoCSV using: Gofer new smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; package: 'ConfigurationOfNeoCSV'; load. (Smalltalk at: #ConfigurationOfNeoCSV) loadBleedingEdge. Any idea? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 9, 2016

IWST16 deadline extension

by Anne Etien

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST16 â International Workshop on Smalltalk Technologies Prague, Czech Republic; August 23th, 2016 http://www.esug.org/wiki/pier/Conferences/2016/International-Workshop-IWST_… <http://www.esug.org/wiki/pier/Conferences/2016/International-Workshop-IWST_…> ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: - Short position papers describing emerging ideas - Long research papers with deeper description of experiments and of research results. - Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: May 22th, 2016 (firm date) Notification deadline: June 20th, 2016 Camera-ready : July 13th, 2016 Workshop : August 23th, 2016 All accepted papers will be published in ACM DL (To be confirmed) Best papers would be extended in an International Journal ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm <http://www.acm.org/sigs/sigplan/authorInformation.htm>. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst20160 <https://easychair.org/conferences/?conf=iwst20160> ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (UniversitÃ© Lyon 2 LumiÃ¨re, France)

May 9, 2016

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

by Henrik Johansen

> On 09 May 2016, at 1:53 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > (Which is a neat storage format for, say, a UIBuilder) > > When you don't touch it, you don't care about it. > > 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. > > I guess because it's written by handâ¦ I mean the array looks like bad attempt at STON. > > In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout. > > Peter Uhuh, in my mind, it seemed to get off to a kind of shaky start, and never improved. Rather than take the opportunity to design a more generic object model for widgets with a clear strategy in mind for mapping to a literal syntax, it seemed to me to have started by copy-pasting the entire API used by Morphic widgets, adding Spec in front of some of the class names, and call it a day. Slap some {}'s around where appropriate, and you have a literal syntax! The good news is, no-one in their right mind would willingly use the literal format as is, so changing it probably wouldn't cause too much of an uproar, the bad new is, all the hard work involved in creating a sensical format, still remains. It's also rather hard to make a good object model that you then later graft a literal format on top of... For instance, with the use of blocks for everything, and the weird mix of symbols and method calls: row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] I'd have no idea how to represent as a literal in an intuitive way. Cheers, Henry

May 9, 2016

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

by Esteban Lorenzano

> On 09 May 2016, at 13:45, Henrik Johansen <henrik.s.johansen(a)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 9, 2016

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

by Peter UhnÃ¡k

> (Which is a neat storage format for, say, a UIBuilder) > When you don't touch it, you don't care about it. > 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. > I guess because it's written by handâ¦ I mean the array looks like bad attempt at STON. In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout. Peter

May 9, 2016

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

by Henrik Johansen

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. Cheers, Henry > On 09 May 2016, at 1:22 , Denis Kudriashov <dionisiydk(a)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 9, 2016