April 2014 - Pharo-dev - lists.pharo.org

Jun for Pharo?

by Pharo4Stef

Hi guys the father of the JUN frameworks told me the following: > Thank you very much, StÃ©phane-san and Serge-san. > > We have another version of Jun under the term of "The Modified BSD License". > It's called "Takenoko" that is subset of "Jun"; dual licensing. > > Please browse the following page to get it. > http://aokilab.kyoto-su.ac.jp/takenoko/index.html > > I'm happy if useful, if you can use it. > > --- AOKI Atsushi Stef

April 11, 2014

Re: [Pharo-dev] MongoGB GridFS driver for Pharo

by Norbert Hartl

Am 11.04.2014 um 11:29 schrieb Stephan Eggermont <stephan(a)stack.nl>: > Roberto wrote: >> What about storing and retrieving documents that exceed the Mongo document size limit? :) > > Pushing large documents through MongoDB might be a pretty bad idea. > I donât find enough google search results to > mongodb "zero-copyâ > and there are no claims that GridFS is fast on the website, only easy. > You might get much better results using a distributed files system (mogilefs?) > Handling large documents in a distributed environment is always pain. But there is no choice if you need it. Iâm not sure how bad GridFS is. On the other hand not one distributed filesystem I encountered in my career was close to be usable. I donât know MogileFs! But it is implemented in perl, so are you serious about it? :) Norbert

April 11, 2014

[ANN] Amber 0.12.4 released

by Nicolas Petton

Deal Smalltalkers, After 3 months of development, we are happy to announce the release of Amber 0.12.4. Highlights: * Several improvements in Helios, including UI-related and debugger improvements * Loading Amber without cloning the repository has been simplified * A new documentation (in progress) can be found at http://docs.amber-lang.net/ Commits: https://github.com/amber-smalltalk/amber/compare/0.12.3...0.12.4 Issues: https://github.com/amber-smalltalk/amber/issues?milestone=12&state=closed API Changes: * Package Canvas renamed to Web * Object >> try:catch: deprecated in favour of BlockClosure >> tryCatch: + Announcer >> + on:do:for: + Node >> + navigationNodeAt:ifAbsent: + BlockClosure >> + tryCatch: + Environment >> + evaluate:for: + AmberCli >> + version: + Object >> + deprecatedAPI: - Environment >> - eval:on: - evaluateString:on: Cheers, Nico -- Nicolas Petton http://nicolas-petton.fr

April 11, 2014

Re: [Pharo-dev] MongoGB GridFS driver for Pharo

by Stephan Eggermont

Roberto wrote: >What about storing and retrieving documents that exceed the Mongo document size limit? :) Pushing large documents through MongoDB might be a pretty bad idea. I donât find enough google search results to mongodb "zero-copyâ and there are no claims that GridFS is fast on the website, only easy. You might get much better results using a distributed files system (mogilefs?) Stephan

April 11, 2014

Re: [Pharo-dev] MongoGB GridFS driver for Pharo

by Norbert Hartl

Am 11.04.2014 um 09:08 schrieb roberto.minelli(a)usi.ch: > > On Apr 10, 2014, at 1:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 10.04.2014 um 11:17 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> Hi, >>> >>> Voyage did not implement GridFS out of the box. >>> But It can be extended to use it, it does not looks as a real complicated API. >>> >> Agreed. But I ask myself what is the use of GridFS in voyage. I would guess that in most use cases the access to GridFS needs to be offloaded of the image. > > What about storing and retrieving documents that exceed the Mongo document size limit? :) > Depends on your use case: If you have a JSON document that exceeds 16MB then you should think about splitting it up and store the child elements as documents in the collection. At the same time you will be able to search in those documents which is IMHO not possible with GridFS at the moment If you have something different and those documents are standalone then you are better off mapping a URI namespace directly via your frontend webserver. [1] [2]. If you need references from a ânormalâ document to a GridFS document then there might be a chance storing it via the image makes sense (2nd case). In those scenarios you have two things that need to be stored separately. The normal documents and GridFS documents cannot be stored in the same collection. case 1: If you decide to make two requests from the client the mapping in the frontend server might come in handy. You would store the GridFS document first getting back a reference (id or URI) to it. That you can store in the normal document and store that document next. On retrieval of the GridFS document it is most likely you query the reference in the normal document. That request would then redirect to the GridFS mapped URI which would be served completely by the frontend server. case 2: You want to make only one request for uploading both in a multipart message. This way it will be really difficult to treat both resources separately by the frontend server. In this case there is barely a chance other then the image receives the multipart message and stores both documents. But that wonât be fast and should only be done if the number uploads of those big things is rather small compared to the retrieval of the same. On retrieval time you should do the same as above: map the GridFS via frontend server and redirect from the image to retrieve the GridFS document. So having GridFS support in the image can be useful while developing and for deploying case 2. So Iâll take it back partially :) But remember that accessing GridFS documents in the image is just copying a lot of bytes from one socket to another. Exactly the kind of things it is not good at. Norbert [1] https://bitbucket.org/onyxmaster/mod_gridfs [2] https://github.com/mdirolf/nginx-gridfs > Cheers, > R > >> >> Norbert >> >>> Esteban >>> >>> On 10 Apr 2014, at 11:07, roberto.minelli(a)usi.ch wrote: >>> >>>> Hi guys, >>>> >>>> I need to store objects (i.e., mongo documents) which exceeds the BSON-document size of 16MB. >>>> >>>> I run into the âofficialâ mongoDB solution, which is to use GridFS. >>>> >>>> Does anyone know if there is any possibility to use GridFS within Pharo? For example with Voyageâ¦ or any other suggestion is highly appreciated! >>>> >>>> Cheers, >>>> Roberto >>> >>> >> >> > >

April 11, 2014

Re: [Pharo-dev] MongoGB GridFS driver for Pharo

by roberto.minelli＠usi.ch

On Apr 10, 2014, at 1:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 10.04.2014 um 11:17 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi, >> >> Voyage did not implement GridFS out of the box. >> But It can be extended to use it, it does not looks as a real complicated API. >> > Agreed. But I ask myself what is the use of GridFS in voyage. I would guess that in most use cases the access to GridFS needs to be offloaded of the image. What about storing and retrieving documents that exceed the Mongo document size limit? :) Cheers, R > > Norbert > >> Esteban >> >> On 10 Apr 2014, at 11:07, roberto.minelli(a)usi.ch wrote: >> >>> Hi guys, >>> >>> I need to store objects (i.e., mongo documents) which exceeds the BSON-document size of 16MB. >>> >>> I run into the âofficialâ mongoDB solution, which is to use GridFS. >>> >>> Does anyone know if there is any possibility to use GridFS within Pharo? For example with Voyageâ¦ or any other suggestion is highly appreciated! >>> >>> Cheers, >>> Roberto >> >> > >

April 11, 2014

Re: [Pharo-dev] Pharo tutorials

by Tyler Sperry

> what is pharo tutorials? I just ran across this issue tonight after installing the 4/10 build of Pharo 3.0 on a Windows netbook. At first I thought it was a 3.0 beta quirk, but no, things worked the same way when I tried it in a fresh 2.0 image as well. The problem is that users get to the tutorials from the "Browse tutorials" window, which has a different behavior than a window created by the tutorial itself. From World > Help > Pharo Tutorials you are in a browser that won't generate menus for selected text. So if you navigate in the left pane to "Welcome" you see text that tells you to select "PharoTutorial next." and right click your way to a "do it (d)" option. The problem is that you can't actually get *any* right click menu for selected right-pane text. I'm a Smalltalk noob, but not a *complete* noob, so I tried Alt+d and sure enough, I got the next Professor Stef lesson in its own window, where the right click menus work fine. Thierry's guess about read only status doesn't seem to totally explain the issue. You can, for example, pick a random lesson in the "Browse tutorials" left pane and the right pane contents will exhibit the same behavior: select + right click doesn't work, but select and Alt+D/P works as expected (I.e. Alt-p will alter the lesson's text.) I can understand why this subject wouldn't show up for most Pharo users: they are experienced Smalltalkers who use the keyboard shortcuts instead of the menus. Given that Pharo isn't targeting beginners it's not a big deal, but I would suggest the text for that first "Welcome" tutorial lesson be changed to tell the student to use Alt+d or Command+d instead of the current frustrating menu suggestion. The second lesson will appear in something like a normal workspace window, and that's where the option of keyboard or mouse menu could be explained. Tyler -- View this message in context: http://forum.world.st/Pharo-tutorials-tp4746757p4754016.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 11, 2014

[OT] Pharo-Amber stack screencast

by Sebastian Sastre

Hi guys, this might be of interest to some: A tour into tasks, a flowing experiment on full-duplex web applications using web sockets http://blog.flowingconcept.com/brandIt/a-tour-into-tasks-a-flowing-experime… Is a ~28m screencast Iâve published in enGrish giving a tour on various details of this little experiment: http://tasks.flowingconcept.com/service/ These screencasts will be feedback-driven so feel free to comment and send suggestions on how to make them better or cover topics you feel need to be proven the most for a broader audience hope you enjoy and donât forget to vote up on youtube if you do! sebastian o/

April 10, 2014

Re: [Pharo-dev] Weak pointer

by Yuriy Tymchuk

No, can you give me a link? On 10 Apr 2014, at 23:38, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > didnât you saw my screencast? > > enGrish rulez big time > > <:o) > > > On Apr 10, 2014, at 12:36 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 2014-04-10 8:21 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> As long as a couple of non-native English speakers are making fun of each other, it's OK ;-) >> >> We're the majority I think. >> > >

April 10, 2014

Re: [Pharo-dev] Weak pointer

by Sebastian Sastre

didnât you saw my screencast? enGrish rulez big time <:o) On Apr 10, 2014, at 12:36 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-04-10 8:21 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> As long as a couple of non-native English speakers are making fun of each other, it's OK ;-) > > We're the majority I think. >

April 10, 2014