- Pharo-users - lists.pharo.org

Re: [Pharo-users] Voyage, selectMany with multiple Root

by Norbert Hartl

Hi Gonzalo, that is indeed something that is missing in voyage to make that kind of queries more easy. But you can do it using something like that itemsForUser: aUser ^ Item selectMany: { 'user.__id' -> aUser voyageId } asDictionary Norbert Am 18.09.2014 um 03:06 schrieb gonza <gonzalogtesta(a)gmail.com>: > Hi people, I've been making a small project using Pharo and Voyage, and > everything is going well, but I'm facing a performance issue when retrieving > items from Mongo. > > I've two classes, one for items, and other for users, and both are Root. > Each item contains the user who created it. > > My question is if there's a best way of querying all items for an user, > using selectMany, when you have a document containing another. > > As work-around, by now, I'm making a selectAll and then filter them on > memory, and that takes a lot of time and memory when the collection grows. > > Can you help on this? > > Thanks, > > Gonzalo > > > > -- > View this message in context: http://forum.world.st/Voyage-selectMany-with-multiple-Root-tp4778705.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 18, 2014

Re: [Pharo-users] Zoomable & Infinitely scrollable PasteupMorph

by Alexandre Bergel

> Ah one thing with roassal: > > Please honor the global keymappings and morph local ones. > > TRMorph swallows them due to the key press related methods which hijack them all. Is there another keystroke than cmd-w ? > Once a TRMorph is active is feels weird. > > I love TRMorph and animations. Very nice code. Thanks! Alexandre > > > > Le 18 sept. 2014 05:46, "Alexandre Bergel" <alexandre.bergel(a)me.com> a Ã©crit : > Yes it can. But Roassal is not made to replace Morphic. > In my opinion, Morphic is not simply about having graphic elements answering events, as Roassal does. Morphic provides ways to build sophisticated UI (even if Morphic behaves poorly in comparison with state-of-the-art UI frameworks). Roassal is made to visualize and interact with data. > > As it is defined today, Roassal is not made to build sophisticated UI. > > Cheers, > Alexandre > > > On Sep 16, 2014, at 10:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Do you think Roassal can replace Morphic at all? > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

Re: [Pharo-users] Zoomable & Infinitely scrollable PasteupMorph

by phil＠highoctane.be

Ah one thing with roassal: Please honor the global keymappings and morph local ones. TRMorph swallows them due to the key press related methods which hijack them all. Once a TRMorph is active is feels weird. I love TRMorph and animations. Very nice code. Phil Le 18 sept. 2014 05:46, "Alexandre Bergel" <alexandre.bergel(a)me.com> a Ã©crit : > Yes it can. But Roassal is not made to replace Morphic. > In my opinion, Morphic is not simply about having graphic elements > answering events, as Roassal does. Morphic provides ways to build > sophisticated UI (even if Morphic behaves poorly in comparison with > state-of-the-art UI frameworks). Roassal is made to visualize and interact > with data. > > As it is defined today, Roassal is not made to build sophisticated UI. > > Cheers, > Alexandre > > > On Sep 16, 2014, at 10:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > Do you think Roassal can replace Morphic at all? > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Sept. 18, 2014

Re: [Pharo-users] STON: Metadata of text and yaml translations

by Tudor Girba

Hi, In your case, you probably do not need to store text (this is what gets in the #text port) but the string correspondent. Just use "text asString" before you store the updated text in your object. Cheers, Doru On Wed, Sep 17, 2014 at 9:02 PM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi Sven, > > > On 09/17/2014 01:30 PM, Sven Van Caekenberghe wrote: > >> Offray, >> >> On 17 Sep 2014, at 18:50, Offray Vladimir Luna CÃ¡rdenas < >> offray(a)riseup.net> wrote: >> >> Hi, >>> >>> Finally, with help in the Moose mailing list (thanks Doru!), I have >>> automatic update of nodes in my outliner, and its working pretty well. >>> >> >> It is good that you are making progress. >> >> > Thanks, and thanks too for your quick answer. > > I'm using STON for persistence and I see that when I update a node body >>> content I got a lot of metadata on the text like runs, text font, text >>> color, lastIndex, lastOfset. For reference I have attached two files, >>> test.1.ston which is the original outline with no updates on nodes and >>> test.2.ston which contains the updated nodes with metadata. >>> >> >> 0. The goal of STON is to produce a faithful, textual, somewhat readable, >> representation of an object graph (with object sharing and circular >> references) that can be read to recreate the same object. JSON was the >> starting point, the inspiration, but JSON is too limited to implement the >> stated goal. >> >> So my questions are: >>> >>> 1. There is any way to exclude the text metadata or to select the >>> "deepness" of the exportation, including just the content of the text, but >>> not the metadata of it? >>> >> >> You can override/reimplement #toSton: and #fromSton: (check the other >> implementors) to customize how your objects are handled. >> >> Looking at your example, I don't really see the problem, you used Text >> instances, so they are serialized as such. This way, potential styling is >> preserved. >> >> > Yes, there is no problem and preserving text styling is a good think. I > was just curious. > > 2. I see that there is a way to export from STON to JSON. There are >>> plans to implement something like YAML[1] export? If not, which would be a >>> good approach to explore the existing code on STON-Core and implement this? >>> >> >> No, that is not a goal/objective at all, there is no framework for that. >> The JSON thing is a hack 'because it could be done', it cannot support the >> stated goal. >> >> 3. I have seen that text string containing a carriage return are stored >>> with "\r" character in them, there is any way to make the text be stored >>> containing actual carriage returns? >>> >> >> STONWriter will escape all dangerous characters by default and this is >> not optional (right now). You are however free to use those characters in >> strings, it should work as expected with STONReader. >> >> From your earlier questions I infer that you want to turn STON in some >> kind of literal programming language. This is quite far from the original >> goal. You are of course free to use STON as inspiration or building block. >> >> > My idea is to create some kind of Open/Garage/Citizen Science Notebook for > interactive documentation and visualization combining Pharo/Roassal/Moose > and I want to use STON or YAML for storing and sharing that notebooks. The > inspiration comes from tools like Leo Editor[1] and IPython Notebook[2] and > Freemind/Docear[3] and some other ideas that I have not seeing elsewhere > (yet ;-)). > > [1] http://leoeditor.com/ > [2] http://ipython.org/notebook.html > [3] https://www.docear.org/ > > Despite of times when I can not advance as fast as I would like or > understand things better, is has been quite a pleasure working with Pharo > communities and tools. > > Thanks again, > > Offray > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 18, 2014

Re: [Pharo-users] Zoomable & Infinitely scrollable PasteupMorph

by Alexandre Bergel

Yes it can. But Roassal is not made to replace Morphic. In my opinion, Morphic is not simply about having graphic elements answering events, as Roassal does. Morphic provides ways to build sophisticated UI (even if Morphic behaves poorly in comparison with state-of-the-art UI frameworks). Roassal is made to visualize and interact with data. As it is defined today, Roassal is not made to build sophisticated UI. Cheers, Alexandre On Sep 16, 2014, at 10:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Do you think Roassal can replace Morphic at all? > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 18, 2014

Voyage, selectMany with multiple Root

by gonza

Hi people, I've been making a small project using Pharo and Voyage, and everything is going well, but I'm facing a performance issue when retrieving items from Mongo. I've two classes, one for items, and other for users, and both are Root. Each item contains the user who created it. My question is if there's a best way of querying all items for an user, using selectMany, when you have a document containing another. As work-around, by now, I'm making a selectAll and then filter them on memory, and that takes a lot of time and memory when the collection grows. Can you help on this? Thanks, Gonzalo -- View this message in context: http://forum.world.st/Voyage-selectMany-with-multiple-Root-tp4778705.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 18, 2014

Solution for memoization

by phil＠highoctane.be

I saw http://www.slideshare.net/esug/memoization-aspects Do we have a memoization package based on that work? Phil

Sept. 17, 2014

Re: [Pharo-users] STON: Metadata of text and yaml translations

by Offray Vladimir Luna CÃ¡rdenas

Hi Sven, On 09/17/2014 01:30 PM, Sven Van Caekenberghe wrote: > Offray, > > On 17 Sep 2014, at 18:50, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > >> Hi, >> >> Finally, with help in the Moose mailing list (thanks Doru!), I have automatic update of nodes in my outliner, and its working pretty well. > > It is good that you are making progress. > Thanks, and thanks too for your quick answer. >> I'm using STON for persistence and I see that when I update a node body content I got a lot of metadata on the text like runs, text font, text color, lastIndex, lastOfset. For reference I have attached two files, test.1.ston which is the original outline with no updates on nodes and test.2.ston which contains the updated nodes with metadata. > > 0. The goal of STON is to produce a faithful, textual, somewhat readable, representation of an object graph (with object sharing and circular references) that can be read to recreate the same object. JSON was the starting point, the inspiration, but JSON is too limited to implement the stated goal. > >> So my questions are: >> >> 1. There is any way to exclude the text metadata or to select the "deepness" of the exportation, including just the content of the text, but not the metadata of it? > > You can override/reimplement #toSton: and #fromSton: (check the other implementors) to customize how your objects are handled. > > Looking at your example, I don't really see the problem, you used Text instances, so they are serialized as such. This way, potential styling is preserved. > Yes, there is no problem and preserving text styling is a good think. I was just curious. >> 2. I see that there is a way to export from STON to JSON. There are plans to implement something like YAML[1] export? If not, which would be a good approach to explore the existing code on STON-Core and implement this? > > No, that is not a goal/objective at all, there is no framework for that. The JSON thing is a hack 'because it could be done', it cannot support the stated goal. > >> 3. I have seen that text string containing a carriage return are stored with "\r" character in them, there is any way to make the text be stored containing actual carriage returns? > > STONWriter will escape all dangerous characters by default and this is not optional (right now). You are however free to use those characters in strings, it should work as expected with STONReader. > > From your earlier questions I infer that you want to turn STON in some kind of literal programming language. This is quite far from the original goal. You are of course free to use STON as inspiration or building block. > My idea is to create some kind of Open/Garage/Citizen Science Notebook for interactive documentation and visualization combining Pharo/Roassal/Moose and I want to use STON or YAML for storing and sharing that notebooks. The inspiration comes from tools like Leo Editor[1] and IPython Notebook[2] and Freemind/Docear[3] and some other ideas that I have not seeing elsewhere (yet ;-)). [1] http://leoeditor.com/ [2] http://ipython.org/notebook.html [3] https://www.docear.org/ Despite of times when I can not advance as fast as I would like or understand things better, is has been quite a pleasure working with Pharo communities and tools. Thanks again, Offray

Sept. 17, 2014

Re: [Pharo-users] STON: Metadata of text and yaml translations

by Sven Van Caekenberghe

Offray, On 17 Sep 2014, at 18:50, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > Hi, > > Finally, with help in the Moose mailing list (thanks Doru!), I have automatic update of nodes in my outliner, and its working pretty well. It is good that you are making progress. > I'm using STON for persistence and I see that when I update a node body content I got a lot of metadata on the text like runs, text font, text color, lastIndex, lastOfset. For reference I have attached two files, test.1.ston which is the original outline with no updates on nodes and test.2.ston which contains the updated nodes with metadata. 0. The goal of STON is to produce a faithful, textual, somewhat readable, representation of an object graph (with object sharing and circular references) that can be read to recreate the same object. JSON was the starting point, the inspiration, but JSON is too limited to implement the stated goal. > So my questions are: > > 1. There is any way to exclude the text metadata or to select the "deepness" of the exportation, including just the content of the text, but not the metadata of it? You can override/reimplement #toSton: and #fromSton: (check the other implementors) to customize how your objects are handled. Looking at your example, I don't really see the problem, you used Text instances, so they are serialized as such. This way, potential styling is preserved. > 2. I see that there is a way to export from STON to JSON. There are plans to implement something like YAML[1] export? If not, which would be a good approach to explore the existing code on STON-Core and implement this? No, that is not a goal/objective at all, there is no framework for that. The JSON thing is a hack 'because it could be done', it cannot support the stated goal. > 3. I have seen that text string containing a carriage return are stored with "\r" character in them, there is any way to make the text be stored containing actual carriage returns? STONWriter will escape all dangerous characters by default and this is not optional (right now). You are however free to use those characters in strings, it should work as expected with STONReader. >From your earlier questions I infer that you want to turn STON in some kind of literal programming language. This is quite far from the original goal. You are of course free to use STON as inspiration or building block. Sven > [1] https://en.wikipedia.org/wiki/YAML > > Thanks, > > Offray > <test.1.ston><test.2.ston>

Sept. 17, 2014

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Sprint Lille 26th september

by Marcus Denker

On 17 Sep 2014, at 16:25, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Where: http://rmod.inria.fr/web/contact > Ups, yes, this is the correct links. > > 2014-09-17 16:24 GMT+02:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > RMoD > > The requested object /web/pier/contact was not found on this server. > > You might want to try one of these options: > > Click on a link on this site. > Jump to the RMoD homepage. > If you typed the page address, make sure that it is spelled correctly. > > 2014-09-17 15:10 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > What? Pharo Sprint > When? Friday, 26th September, starting at 10:00am > > Where? > RMoD, Inria Lille, Building B, third floor > http://rmod.lille.inria.fr/web/pier/contact > > As the building is not open to the public, please contact > us before if you plan to come. > > > >

Sept. 17, 2014