May 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Noncontiguous selections in FastTable?

by Denis Kudriashov

I fixed it in Pharo 6. Look at issue 19277 <https://pharo.fogbugz.com/f/cases/19277/FastTable-not-support-deselection-w…> . Maybe you can just load updated packages for FastTable to fix your problem. 2017-05-20 22:41 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > Any way to get noncontiguous selection working in FTTableMorph in Pharo 5? > > In Windows I cannot get two non-consecutive items to be selected. > Ctrl key causes menu to appear. > Shift key only allows consecutive items. > > See for example this FastTable: > > | ds | > > ds := FTTreeDataSource > roots: (1 to: 1000) > children: [ :data :item | > item depth even > ifTrue: [ 1 to: data / 2 ] > ifFalse: [ 1 to: data - 1 ] ]. > FTTableMorph new > extent: 200 @ 400; > dataSource: ds; > allowDeselection; > beMultipleSelection; > secondarySelectionColor: Color tan; > openInWindow. > > Any help will be appreciated. > Cheers, > > HernÃ¡n > >

May 21, 2017

Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

by monty

Creating two separate DOM subtrees for two descendants of the body element should be faster and consume less memory than creating one subtree for the entire body. You should also consider benchmarking different approaches, and using profiling to identify which of the parsing, querying, network IO, or whatever is your bottleneck before optimizing. > Sent: Saturday, May 20, 2017 at 7:08 AM > From: PBKResearch <peter(a)pbkresearch.co.uk> > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > Monty > > Many thanks for your patient explanation. I would like to try one supplementary question, if I may. Almost all my work involves reading HTML files from the web and extracting relevant sections, and I am trying to work out how to divide the effort between StAX and XPath. For example, if I am reading an article from Frankfurter Allgemeine, I am looking for two tags: > <div id="artikelEinleitung" class="FAZArtikelEinleitung"> > <div class="FAZArtikelText" itemprop="articleBody"> > which contain the intro and body of the article; everything else can be discarded. > > Using StAX, I can find the first <div> with something like this (adapted from your second snippet): > > [((tag := parser peek) isStartTagNamed: 'div') and: [ tag hasAttributes and: [(tag attributeAt: 'class') = 'FAZArtikelEinleitung']]] > whileFalse: [parser next]. > intro := parser nextNode. > > and similarly for the body. I suppose if this is common I could subclass and make this a method. > > Does this look sensible, and is it more efficient than reading the entire body with StAX and locating the relevant sections with XPath? (I have tried this snippet, and it works. My question is really whether this is the best way to go about it?) > > Many thanks for any advice. > > Peter Kenny > > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty > Sent: 17 May 2017 22:10 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > For example, this: > ((StAXHTMLParser onURL: aURLString) > nextElementNamed: 'head') > ifNotNil: [:headElement | ...] > > parses the document upto the next "head" element and returns it and any descendants as a DOM subtree. If there's no next "head" element, it exhausts the event stream looking for one. If you don't want that, test it first: > (parser peek isStartTagNamed: 'head') > ifTrue: [| headElement | > headElement := parser nextNode. > ...]. > > because you now know what kind of DOM subtree the next events represent, #nextNode is used, which builds any DOM subtree out of the next events, including an element with descendants, a string or comment node, or even an entire document (if sent before reading the start-of-document event). So this: > (StAXHTMLParser onURL: aURLString) nextNode > > is equivalent to this: > XMLHTMLParser parseURL: aURLString. > > StAX is more useful with XML than HTML, because XML documents can be huge. > > > Sent: Tuesday, May 16, 2017 at 6:39 PM > > From: PBKResearch <peter(a)pbkresearch.co.uk> > > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > > > Monty > > > > Many thanks for your help. I have followed your advice to start again in a clean Moose 6.1 image, and so far everything is working fine. Apologies for getting you to sort out the results of my stupidity. In Pharo I am really an experienced beginner. > > > > Thanks again > > > > Peter Kenny > > > > -----Original Message----- > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty > > Sent: 16 May 2017 03:37 > > To: pharo-users(a)lists.pharo.org > > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > > > Something went wrong during your upgrade with class initialization. > > > > Installing the latest versions of these projects into a clean image would work, and so would installing the latest XMLParserHTML and XMLParserStAX into the newest Moose-6.1 image (which has the latest XMLParser and XPath). > > > > But if you insist on upgrading your old image, try the latest ConfigurationOfXMLParser (.303.mcz) and ConfigurationOfXPath (.149.mcz) from their PharoExtras repos and install their latest project versions, and do the same with XMLParserHTML and XMLParserStAX (the older versions aren't compatible with newer XMLParser versions). Then open the test runner and run all "XML|XPath" tests. If you get any failures, evaluate this: > > > > #('XML-Parser' 'XPath-Core') do: [:package | > > (SystemNavigation default allClassesInPackageNamed: package) do: [:class | > > class initialize]] > > > > and try running the tests again. > > > > > Sent: Monday, May 15, 2017 at 6:50 PM > > > From: PBKResearch <peter(a)pbkresearch.co.uk> > > > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > > > Subject: [Pharo-users] Problems loading XML System ( was Re: [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > > > > > Monty > > > > > > As an update, I have rebuilt from the Moose 6.0 download. The version of XML-Parser in that was dated 18 July 2016 (configuration monty.233), so I installed versions of XML-Parser-HTML and XML-Parser-StAX contemporary with that. (The respective configurations are monty.48 and monty.39). With these versions all my previous XMLHTMLParser operations work as before, and I have been able to use the StAX parser in a simple way. So I can start exploring as I intended. > > > > > > I have made repeated attempts to update this rebuilt image to more recent versions of the HTML and StAX parsers, and every time I run into the same error reported below. I started from the latest version and worked backwards, but gave up quickly; it takes about 6 minutes on my machine to load and compile a version, and it soon gets tedious. If I feel more enthusiastic tomorrow, I might start working forwards from my current versions. > > > > > > Anyway, I now have a working system with the StaX and HTML parsers, so I can continue to explore. > > > > > > Best wishes > > > > > > Peter Kenny > > > > > > -----Original Message----- > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch > > > Sent: 15 May 2017 20:44 > > > To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> > > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > > > Monty > > > > > > I have just started trying to use the StAX parsers, and I have found that the update has introduced a problem, which means that XMLHTMLParser no longer works on examples I have used before. I updated to ConfigurationOfXMLParser(monty.302), which is the latest version on the smalltalkhub repository, and then used the load version in the class comment, which loads the stable default. Similarly, I loaded ConfigurationOfXMLParserHTML(monty.62) and ConfigurationOfXMLParserStAX(monty.51), again using stable and default. When I try to run the XMLHTMLParser example I quoted below, I get an error message 'MessageNotunderstood: receiver of "critical:" is nil'. The same message comes up with anything else I try with XMLHTMLParser or with StAXHTMLParser. > > > > > > I am not really up to using the debugger on someone else's code, but the one thing I can see is that the problem lies in XMLKeyValueCache>>critical:, which has the code: > > > ^ self mutex critical: aBlock > > > The problem being that mutex is nil. > > > > > > In my enthusiasm, I saved the updated image with the same name as the old image, which is now therefore overwritten. If I cannot solve this problem, my only way out is to rebuild my image from the Moose 6.0 download. Any suggestions gratefully received. > > > > > > Thanks in advance > > > > > > Peter Kenny > > > > > > -----Original Message----- > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch > > > Sent: 15 May 2017 19:16 > > > To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> > > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > > > Monty > > > > > > Many thanks for this. My original purpose was just to answer Paul deBruicker's query, namely to parse an html file and stop reading at the end of the <head> section. I solved this by trial and error using the code shown below ( which actually stops at the opening tag of the body). This was not my problem at all, but Paul's; I just tackled it for fun. > > > > > > However, you note has prompted me to update my version of the whole XML system - I was using the version I downloaded with Moose 6.0, which was dated August 2016. I am looking at the StAX parsers as a possible way of simplifying what I currently do, which involves downloading an entire web page as a DOM and then manipulating it with XPath to extract the bits I am interested in. I may be able to use StAX to do some of the selection and manipulation as I am reading. > > > > > > It's all a new topic to me, so I foresee a lot of experimentation. It all helps to keep the grey matter active. > > > > > > Thanks again > > > > > > Peter Kenny > > > > > > -----Original Message----- > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty > > > Sent: 15 May 2017 12:15 > > > To: pharo-users(a)lists.pharo.org > > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > > > For that kind of incremental parsing, you could also use XMLParserStAX, a pull-parser that parses a document as a stream of event objects you control with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages like #nextNode, #nextElement, and #nextElementNamed:, which return the next event object(s) as DOM subtrees (searchable with XPath). See the StAXParser class comment for an example. (The StAXHTMLParser class requires XMLParserHTML be installed to work.) > > > > > > > > > > > > > > > > > > > > > > > >

May 21, 2017

Re: [Pharo-users] SmalltalkImage current vm canHandleShiftPressed giving false.

by phil＠highoctane.be

A nice side effect will be that SDL is going to be supported by WebAssembly. Phil On Sat, May 20, 2017 at 10:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Super annoying. This is why we want to get rid of all the event logic and > get it from SDL20. > > Stef > > On Sat, May 20, 2017 at 8:01 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> I was looking in the code of GTSpotter and noticed that we have got: >> >> SmalltalkImage current vm canHandleShiftPressed >> >> in there. >> >> I wanted to see the result because of GTSpotter using that for providing >> hints. >> >> And on Windows, the returned value is false. >> >> Which is weird and annoying. >> >> Is this normal behavior? >> >> Phil >> > >

May 20, 2017

Noncontiguous selections in FastTable?

by HernÃ¡n Morales Durand

Any way to get noncontiguous selection working in FTTableMorph in Pharo 5? In Windows I cannot get two non-consecutive items to be selected. Ctrl key causes menu to appear. Shift key only allows consecutive items. See for example this FastTable: | ds | ds := FTTreeDataSource roots: (1 to: 1000) children: [ :data :item | item depth even ifTrue: [ 1 to: data / 2 ] ifFalse: [ 1 to: data - 1 ] ]. FTTableMorph new extent: 200 @ 400; dataSource: ds; allowDeselection; beMultipleSelection; secondarySelectionColor: Color tan; openInWindow. Any help will be appreciated. Cheers, HernÃ¡n

May 20, 2017

Re: [Pharo-users] SmalltalkImage current vm canHandleShiftPressed giving false.

by Stephane Ducasse

Super annoying. This is why we want to get rid of all the event logic and get it from SDL20. Stef On Sat, May 20, 2017 at 8:01 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I was looking in the code of GTSpotter and noticed that we have got: > > SmalltalkImage current vm canHandleShiftPressed > > in there. > > I wanted to see the result because of GTSpotter using that for providing > hints. > > And on Windows, the returned value is false. > > Which is weird and annoying. > > Is this normal behavior? > > Phil >

May 20, 2017

SmalltalkImage current vm canHandleShiftPressed giving false.

by phil＠highoctane.be

I was looking in the code of GTSpotter and noticed that we have got: SmalltalkImage current vm canHandleShiftPressed in there. I wanted to see the result because of GTSpotter using that for providing hints. And on Windows, the returned value is false. Which is weird and annoying. Is this normal behavior? Phil

May 20, 2017

Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

by PBKResearch

Monty Many thanks for your patient explanation. I would like to try one supplementary question, if I may. Almost all my work involves reading HTML files from the web and extracting relevant sections, and I am trying to work out how to divide the effort between StAX and XPath. For example, if I am reading an article from Frankfurter Allgemeine, I am looking for two tags: <div id="artikelEinleitung" class="FAZArtikelEinleitung"> <div class="FAZArtikelText" itemprop="articleBody"> which contain the intro and body of the article; everything else can be discarded. Using StAX, I can find the first <div> with something like this (adapted from your second snippet): [((tag := parser peek) isStartTagNamed: 'div') and: [ tag hasAttributes and: [(tag attributeAt: 'class') = 'FAZArtikelEinleitung']]] whileFalse: [parser next]. intro := parser nextNode. and similarly for the body. I suppose if this is common I could subclass and make this a method. Does this look sensible, and is it more efficient than reading the entire body with StAX and locating the relevant sections with XPath? (I have tried this snippet, and it works. My question is really whether this is the best way to go about it?) Many thanks for any advice. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty Sent: 17 May 2017 22:10 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) For example, this: ((StAXHTMLParser onURL: aURLString) nextElementNamed: 'head') ifNotNil: [:headElement | ...] parses the document upto the next "head" element and returns it and any descendants as a DOM subtree. If there's no next "head" element, it exhausts the event stream looking for one. If you don't want that, test it first: (parser peek isStartTagNamed: 'head') ifTrue: [| headElement | headElement := parser nextNode. ...]. because you now know what kind of DOM subtree the next events represent, #nextNode is used, which builds any DOM subtree out of the next events, including an element with descendants, a string or comment node, or even an entire document (if sent before reading the start-of-document event). So this: (StAXHTMLParser onURL: aURLString) nextNode is equivalent to this: XMLHTMLParser parseURL: aURLString. StAX is more useful with XML than HTML, because XML documents can be huge. > Sent: Tuesday, May 16, 2017 at 6:39 PM > From: PBKResearch <peter(a)pbkresearch.co.uk> > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > Monty > > Many thanks for your help. I have followed your advice to start again in a clean Moose 6.1 image, and so far everything is working fine. Apologies for getting you to sort out the results of my stupidity. In Pharo I am really an experienced beginner. > > Thanks again > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty > Sent: 16 May 2017 03:37 > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Problems loading XML System ( was [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > Something went wrong during your upgrade with class initialization. > > Installing the latest versions of these projects into a clean image would work, and so would installing the latest XMLParserHTML and XMLParserStAX into the newest Moose-6.1 image (which has the latest XMLParser and XPath). > > But if you insist on upgrading your old image, try the latest ConfigurationOfXMLParser (.303.mcz) and ConfigurationOfXPath (.149.mcz) from their PharoExtras repos and install their latest project versions, and do the same with XMLParserHTML and XMLParserStAX (the older versions aren't compatible with newer XMLParser versions). Then open the test runner and run all "XML|XPath" tests. If you get any failures, evaluate this: > > #('XML-Parser' 'XPath-Core') do: [:package | > (SystemNavigation default allClassesInPackageNamed: package) do: [:class | > class initialize]] > > and try running the tests again. > > > Sent: Monday, May 15, 2017 at 6:50 PM > > From: PBKResearch <peter(a)pbkresearch.co.uk> > > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > > Subject: [Pharo-users] Problems loading XML System ( was Re: [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) > > > > Monty > > > > As an update, I have rebuilt from the Moose 6.0 download. The version of XML-Parser in that was dated 18 July 2016 (configuration monty.233), so I installed versions of XML-Parser-HTML and XML-Parser-StAX contemporary with that. (The respective configurations are monty.48 and monty.39). With these versions all my previous XMLHTMLParser operations work as before, and I have been able to use the StAX parser in a simple way. So I can start exploring as I intended. > > > > I have made repeated attempts to update this rebuilt image to more recent versions of the HTML and StAX parsers, and every time I run into the same error reported below. I started from the latest version and worked backwards, but gave up quickly; it takes about 6 minutes on my machine to load and compile a version, and it soon gets tedious. If I feel more enthusiastic tomorrow, I might start working forwards from my current versions. > > > > Anyway, I now have a working system with the StaX and HTML parsers, so I can continue to explore. > > > > Best wishes > > > > Peter Kenny > > > > -----Original Message----- > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch > > Sent: 15 May 2017 20:44 > > To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > Monty > > > > I have just started trying to use the StAX parsers, and I have found that the update has introduced a problem, which means that XMLHTMLParser no longer works on examples I have used before. I updated to ConfigurationOfXMLParser(monty.302), which is the latest version on the smalltalkhub repository, and then used the load version in the class comment, which loads the stable default. Similarly, I loaded ConfigurationOfXMLParserHTML(monty.62) and ConfigurationOfXMLParserStAX(monty.51), again using stable and default. When I try to run the XMLHTMLParser example I quoted below, I get an error message 'MessageNotunderstood: receiver of "critical:" is nil'. The same message comes up with anything else I try with XMLHTMLParser or with StAXHTMLParser. > > > > I am not really up to using the debugger on someone else's code, but the one thing I can see is that the problem lies in XMLKeyValueCache>>critical:, which has the code: > > ^ self mutex critical: aBlock > > The problem being that mutex is nil. > > > > In my enthusiasm, I saved the updated image with the same name as the old image, which is now therefore overwritten. If I cannot solve this problem, my only way out is to rebuild my image from the Moose 6.0 download. Any suggestions gratefully received. > > > > Thanks in advance > > > > Peter Kenny > > > > -----Original Message----- > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch > > Sent: 15 May 2017 19:16 > > To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > Monty > > > > Many thanks for this. My original purpose was just to answer Paul deBruicker's query, namely to parse an html file and stop reading at the end of the <head> section. I solved this by trial and error using the code shown below ( which actually stops at the opening tag of the body). This was not my problem at all, but Paul's; I just tackled it for fun. > > > > However, you note has prompted me to update my version of the whole XML system - I was using the version I downloaded with Moose 6.0, which was dated August 2016. I am looking at the StAX parsers as a possible way of simplifying what I currently do, which involves downloading an entire web page as a DOM and then manipulating it with XPath to extract the bits I am interested in. I may be able to use StAX to do some of the selection and manipulation as I am reading. > > > > It's all a new topic to me, so I foresee a lot of experimentation. It all helps to keep the grey matter active. > > > > Thanks again > > > > Peter Kenny > > > > -----Original Message----- > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of monty > > Sent: 15 May 2017 12:15 > > To: pharo-users(a)lists.pharo.org > > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > > > For that kind of incremental parsing, you could also use XMLParserStAX, a pull-parser that parses a document as a stream of event objects you control with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages like #nextNode, #nextElement, and #nextElementNamed:, which return the next event object(s) as DOM subtrees (searchable with XPath). See the StAXParser class comment for an example. (The StAXHTMLParser class requires XMLParserHTML be installed to work.) > > > > > > > > > > > > >

May 20, 2017

Re: [Pharo-users] Ston feature idea?

by Sven Van Caekenberghe

> On 19 May 2017, at 10:39, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > Thanks for this interesting conversation. I had some similar problem with Grafoscopio notebooks being to big when I run the default serializer because it puts data about the Text object and some other info about runs. What I did was to flat the tree to contain only the info I need. I solved this with two methods (listed below). Maybe this can be helpful: > > GrafoscopioNotebook>>exportAsSton: aNotebook on: aFileStream > | stonPrettyString | > aNotebook flatten. > stonPrettyString := String streamContents: [ :stream | > (STON writer on: stream) > newLine: String crlf; > prettyPrint: true; > keepNewLines: true; > nextPut: aNotebook children]. > aFileStream nextPutAll: stonPrettyString Any reason why you first write to a string and then directly put that string on aFileStream ? You can directly write STON on aFileStream, which is more memory efficient, as in (STON writer on: aFileStream) If speed is important, it is best to wrap a ZnBufferedWriteStream around it. > GrafoscopioNode>>flatten > "I traverse the tree looking for node bodies containing 'Text' objects and transform them to > their string content, so space is saved and storage format is DVCS friendly while serializing > them to STON" > > (self preorderTraversal) do: [ :eachNode | > (eachNode body class = Text) > ifTrue: [eachNode body: (eachNode body asString)]] > > > Cheers, > > Offray > > On 17/05/17 09:15, Cyril Ferlicot D. wrote: >> On 17/05/2017 16:02, Sven Van Caekenberghe wrote: >>> OK, that is an understandable example. >>> >>> But why exactly do you want Currency to be serialised differently ? You don't want too many instances ? You want all instances to be #== ? Is Currency too big ? You want to allow humans to edit the STON file ? What ? Why ? >>> >>> You can easily make it Currency['Euro'] or even Currency[#Euro] like it is already done for a number of built-in classes. >>> >>> The last example that I gave solved the 'too many instances', make them #== issue. >>> >>> If it is size, that got covered too, but you must solve the problem of how the receiving end will resolve the reference then. >>> >>> But since that is all no good, there must still be another requirement. >> Here it is a simple example to show what I want. >> >> The real use case is that in Moose, entities are really connected to >> their model, and if one of our classes contains an entity it would >> produce a really really really big ston file since it would export >> millions of entities. >> >> But there is a way to retrieve an entity of this model from its moose name. >> >> Thus, I would like to export only the moose name of the entities, then >> get the corresponding entity from a Model the user would have load >> before during the ston reading. >> >>> >> > >

May 19, 2017

Re: [Pharo-users] Anyone knows how to get the list of available archetype with Pillar?

by phil＠highoctane.be

It is just a matter of running a sudo docker command. *I've building a lot of books using that approach this afternoon without a hitch.* *Phil* On Fri, May 19, 2017 at 9:54 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Alexandre and you can create your own template. > Check the way it is done. > I'm working on removing the dependencies to magritte but I got stuck > because of PharoDays and next week I'm teaching > in Tunisia. > > Stef > > On Fri, May 19, 2017 at 4:03 PM, Damien Pollet < > damien.pollet+pharo(a)gmail.com> wrote: > >> There is one archtype for each directory under https://github.com/pilla >> r-markup/Pillar-Archetype >> >> On 19 May 2017 at 15:50, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> >>> Hello! >>> >>> Still on my quest to use Pillar :-) >>> >>> What are the different Archetypes available for Pillar? >>> It would be great to have: ./pillar archetype >>> to obtain the list of available archetype :-) >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >

May 19, 2017

Re: [Pharo-users] Ston feature idea?

by Stephane Ducasse

would be nice to collect all these tips and tricks for STON. On Fri, May 19, 2017 at 10:39 AM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > Thanks for this interesting conversation. I had some similar problem with > Grafoscopio notebooks being to big when I run the default serializer > because it puts data about the Text object and some other info about runs. > What I did was to flat the tree to contain only the info I need. I solved > this with two methods (listed below). Maybe this can be helpful: > > GrafoscopioNotebook>>exportAsSton: aNotebook on: aFileStream > | stonPrettyString | > aNotebook flatten. > stonPrettyString := String streamContents: [ :stream | > (STON writer on: stream) > newLine: String crlf; > prettyPrint: true; > keepNewLines: true; > nextPut: aNotebook children]. > aFileStream nextPutAll: stonPrettyString > > > GrafoscopioNode>>flatten > "I traverse the tree looking for node bodies containing 'Text' objects > and transform them to > their string content, so space is saved and storage format is DVCS > friendly while serializing > them to STON" > > (self preorderTraversal) do: [ :eachNode | > (eachNode body class = Text) > ifTrue: [eachNode body: (eachNode body asString)]] > > > Cheers, > > Offray > > > On 17/05/17 09:15, Cyril Ferlicot D. wrote: > >> On 17/05/2017 16:02, Sven Van Caekenberghe wrote: >> >>> OK, that is an understandable example. >>> >>> But why exactly do you want Currency to be serialised differently ? You >>> don't want too many instances ? You want all instances to be #== ? Is >>> Currency too big ? You want to allow humans to edit the STON file ? What ? >>> Why ? >>> >>> You can easily make it Currency['Euro'] or even Currency[#Euro] like it >>> is already done for a number of built-in classes. >>> >>> The last example that I gave solved the 'too many instances', make them >>> #== issue. >>> >>> If it is size, that got covered too, but you must solve the problem of >>> how the receiving end will resolve the reference then. >>> >>> But since that is all no good, there must still be another requirement. >>> >> Here it is a simple example to show what I want. >> >> The real use case is that in Moose, entities are really connected to >> their model, and if one of our classes contains an entity it would >> produce a really really really big ston file since it would export >> millions of entities. >> >> But there is a way to retrieve an entity of this model from its moose >> name. >> >> Thus, I would like to export only the moose name of the entities, then >> get the corresponding entity from a Model the user would have load >> before during the ston reading. >> >> >>> >> > >

May 19, 2017