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

Re: [Pharo-users] self in Nautilus

by Tudor Girba

Hi, > On Jan 27, 2017, at 9:59 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Hi all, > > in Nautilus, `self` is always the current class instance. This is great for coding class side methods because we can test code fragments live in the editor, but for instance side methods I have not seen the usefulness of it. At times it can even be confusing and cause errors since a "print it" of it looks quite like an instance (`a Listener` vs `Listener`). > > Is there a rationale why `self` in instance view does not raise an error or is nil? That is because you can write: self new and work with an instance. > And, more importantly, could there be a way to set it to a specific value (= can we browse a class with self bound to an specific instance). > This would resemble programming in the debugger, but provide the overview that a class browser provides. You can do that to some extent in the Meta tab of the inspector. Cheers, Doru > cheers, > Siemen > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Jan. 27, 2017

self in Nautilus

by Siemen Baader

Hi all, in Nautilus, `self` is always the current class instance. This is great for coding class side methods because we can test code fragments live in the editor, but for instance side methods I have not seen the usefulness of it. At times it can even be confusing and cause errors since a "print it" of it looks quite like an instance (`a Listener` vs `Listener`). Is there a rationale why `self` in instance view does not raise an error or is nil? And, more importantly, could there be a way to set it to a specific value (= can we browse a class with self bound to an specific instance). This would resemble programming in the debugger, but provide the overview that a class browser provides. cheers, Siemen

Jan. 27, 2017

Re: [Pharo-users] I'd really love to use Pharo this way

by Ben Coman

On Fri, Jan 27, 2017 at 3:36 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > > > On 26/01/17 05:43, Serge Stinckwich wrote: >> >> On Wed, Jan 25, 2017 at 10:29 PM, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >>> >>> Hi Jose, >>> >>> I'm building something that has ideas borrowed from Jupyter notebook[a], >>> Leo >>> Editor[b] and Pharo/Smalltalk and few other original ones. The more I see >>> the connections between stuff like Eve[1], org-mode[2], Jupyter Lab[3], I >>> think that the time for literate computing[4] (a development beyond >>> literal >>> programming), reproducible research and live coding is coming. >>> >>> [a] http://jupyter.org/ >>> [b] http://leoeditor.com/ >>> [1] >>> >>> https://hackernoon.com/smalltalk-and-protein-programming-4da245ac93e2#.2riw… >>> [2] https://www.jstatsoft.org/article/view/v046i03 >>> [3] http://jupyterlab.github.io/jupyterlab/ >>> [4] >>> >>> http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives… >> >> I'm currently using Jupyter notebook with some of my students for >> doing simulation of dynamical systems and they love it I guess. I'm >> not a big fan of the UI because it still looks like a web page and the >> interaction is still somewhat limited compared to what you can do with >> Pharo. >> I'm also a big fan of org-mode and even more powefull than Jupyter >> notebooks because you can mix different computer languages at the same >> time and there is a real support for folding. > > > Yes, I am not a big fan of Jupyter notebook neither. Sounds kind of mean, > but the actual interface is like a glorified REPL log, powered by HTML > output, with a linear sequence of single input/output pair of cells. So > notebooks authors have two options: split the document into several files, > loosing the general overview of the document or a single long "reel" of REPL > log, with too much detail at the same time (I have experience this by myself > [1]). I think that org-mode and interactive outliners (as exemplified in > [2][3]) are better suited to manage exploratory literate computing, > interactive documentation, and the "emergent" order that writing implies. > > [1] http://mutabit.com/repos.fossil/piamed/doc/tip/Afiche/narrativa.png > [2] https://youtu.be/dljNabciEGg > [3] http://xiki.org/screencasts/ > > >> If you remember I have >> done a small show us "your project" last ESUG about some experience I >> have done about be able to run Pharo code inside org-mode. > > > Yes, I remember :-). I was also the "USB guy" in the orange cap team :-P, so > I was taking care of logistics and didn't see as much as I would like of the > event :-/ > >> >> At the moment, we are quite interested in my research group to be able >> to a kind of literate style of computing for modeling and simulation >> of complex systems like simulation of epidemiology models. This is >> something we can do with Jupyter but would be even more interesting in >> the context of Pharo. >> >> Eve looks also very interesting but I have to read more about this one. > > [...] >> >> I really like what you done until now with Grafoscopio and I will try >> to help and use it for own work in the future. > > > Because of the uniform, moldable and integrated nature of Pharo, I think > that Grafoscopio, even in its early stages, prototypes stuff that others, > like Jupyter Lab, are trying to reach, for example trying to go beyond the > notebook and having a extensible computing environment available to the > notebooks. With Grafoscopio we already have that (thanks to being "inside" > Pharo). > > Maybe a first try to integrate our work could be to have some Kendrick > notebook in Grafoscopio. I have to fix some important bugs, but Grafoscopio > is already usable for this kind of scenario and, of course, any help is more > that welcomed! > > (There is still a nasty bug about playgrounds that produce text output > replacing the playground code, but I hope to fix it soon). > >> I have to look to Fossil. Is it possible to linked in someways to git ? > > > Yes, there is some fossil to git bridge. I will try to give support to > fossil first, to have a smooth integrated experience, but that doesn't > preclude the use of other DVCS to work with. > >> I was thinking that maybe that I will submit a gsoc proposal to have >> some support in Jupyter notebooks for Pharo. >> Apparently this not that difficult to built a basic support and after >> that we can built some elaborate on top of it. >> What do you about that ? >> >> Regards, > > > I would like better a GSoC proposal to improve Grafoscopio, as a literate > computing environment for Pharo. This sounds like a good idea. If the project proposal compares and contrasts with the competitors, as well as showing why its not a "me-too" project, this would highlight the advantages of Pharo's approach and why its a worthwhile ecosystem for GSoC to support. cheers -ben > Jupyter is popular but pretty limited in > terms of the notebooks document model and the moldabiliy of the environment > or the live coding capabilities (but it's improving). For me, the big > advantage of Jupyter or Org-mode is their language agnostic architecture, > while Grafoscopio is focused on Pharo/Smalltalk. But language specific > computing suites (like RStudio) are still appealing for projects like GSoC. > > A Grafoscopio GSoC proposal would try to improve several items: > > - User interface and functionality: Keyboard shorcuts, GUI bugs, integrated > pdf export (via pandoc/LaTeX), integrated asynchronous lightweight > collaboration on documents (via fossil DVCS). > - Better test coverage and improving code quality in general. > > GSoC rules doesn't allow being a mentor and a student, so I can not mentor > myself (despite of me kind of doing so with this project :-P). I would > really like to have someone mentoring me this project, helping me with my > knowledge gaps, Spec specific issues, coding in general. > > So, would anyone of the seasoned Pharoers like to mentor this project? I'm > pretty self motivated, but having some guide for this summer to improve my > coding skills with a valuable project for the community will make a big > difference. > > Cheers, > > Offray >

Jan. 27, 2017

Re: [Pharo-users] [Pharo-dev] Pharo by Example 50 released!

by stepharong

I should publish the HTML version and put in on the web. Just no time. .... Stef > Both PDF and HTML version are built automagically each time we commit to > the github repository so you do not need to way, just tell people to > always visit to be kept up to date > > PDF version > > https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… > > HTML version > > https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSucces… > > each folder contains both pdf and html version of each chapter, enjoy :) > On Sun, Jan 22, 2017 at 6:11 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: >> Great work, can't wait for the HTML version (to link to when answering >> questions). >> >> Thank you ! >> >>> On 22 Jan 2017, at 16:53, stepharong <stepharong(a)free.fr> wrote: >>> >>> https://pharoweekly.wordpress.com/2017/01/22/pharo-by-example-50-released/ >>> >>> Super special thanks to Nicolai Hess that pushed me to do the last >>> steps to release. >>> Thanks Nicolai your steady commits pushed me! >>> >>> Stef >>> >> >> -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

Re: [Pharo-users] I'd really love to use Pharo this way

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 26/01/17 05:43, Serge Stinckwich wrote: > On Wed, Jan 25, 2017 at 10:29 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Hi Jose, >> >> I'm building something that has ideas borrowed from Jupyter notebook[a], Leo >> Editor[b] and Pharo/Smalltalk and few other original ones. The more I see >> the connections between stuff like Eve[1], org-mode[2], Jupyter Lab[3], I >> think that the time for literate computing[4] (a development beyond literal >> programming), reproducible research and live coding is coming. >> >> [a] http://jupyter.org/ >> [b] http://leoeditor.com/ >> [1] >> https://hackernoon.com/smalltalk-and-protein-programming-4da245ac93e2#.2riw… >> [2] https://www.jstatsoft.org/article/view/v046i03 >> [3] http://jupyterlab.github.io/jupyterlab/ >> [4] >> http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives… > I'm currently using Jupyter notebook with some of my students for > doing simulation of dynamical systems and they love it I guess. I'm > not a big fan of the UI because it still looks like a web page and the > interaction is still somewhat limited compared to what you can do with > Pharo. > I'm also a big fan of org-mode and even more powefull than Jupyter > notebooks because you can mix different computer languages at the same > time and there is a real support for folding. Yes, I am not a big fan of Jupyter notebook neither. Sounds kind of mean, but the actual interface is like a glorified REPL log, powered by HTML output, with a linear sequence of single input/output pair of cells. So notebooks authors have two options: split the document into several files, loosing the general overview of the document or a single long "reel" of REPL log, with too much detail at the same time (I have experience this by myself [1]). I think that org-mode and interactive outliners (as exemplified in [2][3]) are better suited to manage exploratory literate computing, interactive documentation, and the "emergent" order that writing implies. [1] http://mutabit.com/repos.fossil/piamed/doc/tip/Afiche/narrativa.png [2] https://youtu.be/dljNabciEGg [3] http://xiki.org/screencasts/ > If you remember I have > done a small show us "your project" last ESUG about some experience I > have done about be able to run Pharo code inside org-mode. Yes, I remember :-). I was also the "USB guy" in the orange cap team :-P, so I was taking care of logistics and didn't see as much as I would like of the event :-/ > > At the moment, we are quite interested in my research group to be able > to a kind of literate style of computing for modeling and simulation > of complex systems like simulation of epidemiology models. This is > something we can do with Jupyter but would be even more interesting in > the context of Pharo. > > Eve looks also very interesting but I have to read more about this one. [...] > I really like what you done until now with Grafoscopio and I will try > to help and use it for own work in the future. Because of the uniform, moldable and integrated nature of Pharo, I think that Grafoscopio, even in its early stages, prototypes stuff that others, like Jupyter Lab, are trying to reach, for example trying to go beyond the notebook and having a extensible computing environment available to the notebooks. With Grafoscopio we already have that (thanks to being "inside" Pharo). Maybe a first try to integrate our work could be to have some Kendrick notebook in Grafoscopio. I have to fix some important bugs, but Grafoscopio is already usable for this kind of scenario and, of course, any help is more that welcomed! (There is still a nasty bug about playgrounds that produce text output replacing the playground code, but I hope to fix it soon). > I have to look to Fossil. Is it possible to linked in someways to git ? Yes, there is some fossil to git bridge. I will try to give support to fossil first, to have a smooth integrated experience, but that doesn't preclude the use of other DVCS to work with. > I was thinking that maybe that I will submit a gsoc proposal to have > some support in Jupyter notebooks for Pharo. > Apparently this not that difficult to built a basic support and after > that we can built some elaborate on top of it. > What do you about that ? > > Regards, I would like better a GSoC proposal to improve Grafoscopio, as a literate computing environment for Pharo. Jupyter is popular but pretty limited in terms of the notebooks document model and the moldabiliy of the environment or the live coding capabilities (but it's improving). For me, the big advantage of Jupyter or Org-mode is their language agnostic architecture, while Grafoscopio is focused on Pharo/Smalltalk. But language specific computing suites (like RStudio) are still appealing for projects like GSoC. A Grafoscopio GSoC proposal would try to improve several items: - User interface and functionality: Keyboard shorcuts, GUI bugs, integrated pdf export (via pandoc/LaTeX), integrated asynchronous lightweight collaboration on documents (via fossil DVCS). - Better test coverage and improving code quality in general. GSoC rules doesn't allow being a mentor and a student, so I can not mentor myself (despite of me kind of doing so with this project :-P). I would really like to have someone mentoring me this project, helping me with my knowledge gaps, Spec specific issues, coding in general. So, would anyone of the seasoned Pharoers like to mentor this project? I'm pretty self motivated, but having some guide for this summer to improve my coding skills with a valuable project for the community will make a big difference. Cheers, Offray

Jan. 26, 2017

Re: [Pharo-users] [Seaside] Bad Request ZnEntityTooLarge

by Bernhard Pieber

> Am 21.01.2017 um 15:12 schrieb Ben Coman <btc(a)openInWorld.com>: > On Sat, Jan 21, 2017 at 1:22 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > Hi Johan, > > Thank you for your detailed answer. See below. > > Am 20.01.2017 um 10:12 schrieb Johan Brichau <johan(a)inceptive.be>: > > > > imho, itâs better practice to detect too large file upload in your app on the client side, i.e. before your user has been uploading xxx MB. For that, you can check out various client-side programs like jQuery-FileUpload (https://blueimp.github.io/jQuery-File-Upload/) > Thanks for the pointer. I will look into adding somthing like this on the client side. Someone mentioned using Dropzone.js from Seaside. I had searched stackoverflow for limiting upload file size and found some helpful tips: > http://stackoverflow.com/questions/11514166/check-file-size-before-upload > > However, I also found warnings like these: > âKeep in mind that even if it's now possible to validate on the client, you should still validate it on the server, though. All client side validations can be bypassed.â > âOf course, this â¦ can be tampered with so always use server side validation.â > > This is why I wanted to find a user-friendly way to prevent this from my server code. Are you saying, this is not necessary in your opinion? > > > In general I'd say... If someone is smart-enough and wicked enough to bypass your client side checks, you don't need to be user-friendly to them. The server checks are more to protect your server from them. You are right. I am convinced. I will add client side checks. Thanks for your answer, Ben. Cheers, Bernhard

Jan. 26, 2017

Re: [Pharo-users] Deployment pharo with multiple instances and voyage

by Alexandre Bergel

+1 > Le 26 janv. 2017 Ã 16:10, stepharong <stepharong(a)free.fr> a Ã©crit : > > This is great > I would love to know what is your application and we should add it in the success stories. > > Stef > >> Hi! >> >> Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I have been playing with it and everything works ok with a single Pharo image. >> >> Couple of days ago I started questioning myself about how voyage behaves when you have multiple pharo images using the same mongo database (horizontal scaling). I want to know how the cache of voyage behaves in a scenario with object updates. >> >> Example: ââââââââââââââ >> Imagine I have two images A and B. >> >> - Image A query for object o and voyage put it in the cache. >> - Image B query for object o and voyage put it in the cache. >> - Image A updates object o and push it into the database calling #save. >> - Image B query for object o that should be already in the cache. >> >> In this case, does Image B see the changes performed by image A? >> ââââââââââââââ >> >> All ideas are welcome :) >> >> Thanks and cheers! >> Alejandro > > > -- > Using Opera's mail client: http://www.opera.com/mail/ >

Jan. 26, 2017

Re: [Pharo-users] Deployment pharo with multiple instances and voyage

by stepharong

This is great I would love to know what is your application and we should add it in the success stories. Stef > Hi! > > Iâm close to deploy a web service using Pharo with Voyage and MongoDB. I > have been playing with it and everything works ok with a single Pharo > image. > > Couple of days ago I started questioning myself about how voyage behaves > when you have multiple pharo images using the same mongo database > (horizontal scaling). I want to know how the cache of voyage behaves in > a scenario with object updates. > > Example: ââââââââââââââ > Imagine I have two images A and B. > > - Image A query for object o and voyage put it in the cache. > - Image B query for object o and voyage put it in the cache. > - Image A updates object o and push it into the database calling #save. > - Image B query for object o that should be already in the cache. > > In this case, does Image B see the changes performed by image A? > ââââââââââââââ > > All ideas are welcome :) > > Thanks and cheers! > Alejandro -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

Re: [Pharo-users] Deployment pharo with multiple instances and voyage

by Henrik Johansen

> On 25 Jan 2017, at 22:39 , Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > > Cool! Thanks for the answers! > > Norbert mentions something interesting about references. > I have found that even though on each query mongo get the up-to-date version of the objects, it does not install the proxies to look for the up-to-date versions of the references of the queried object. > > I made the following experiment: > Having two images 1 and 2 and two classes A and B, each of them having one instance variable. > âââââââââ > Image 1 (Create two objects, âaâ referencing âbâ) > [ |a b| > a := A new. > b := B new > a setInstVar: b. > b setInstVar: âfoo'. > b save. > a save. > ] > > Image 2 (Mutates the second object, but the first is not changed) > [ > b := (repository selectAll: A) first instVar. > b setInstVar: âbarâ. > b save. > ] > > Image 1 (Query the first object and access to the referenced object) > [ > b := (repository selectAll: A) first instVar. > b instVar. â-> fooâ > b := (repository selectAll: B) first. > b instVar. â-> bar" > ] > > This little experiment showed me that I cannot trust on the state of other objects that I have not explicitly queried for. > > Is there any way of solving this without creating new instances of voyage repositories for each request? > > Thanks! > Alejandro Three, actually ;) - Accept that an image will contain some stale values, and deal with conflicts at save time. This is the most performant/scalable. - Always save only root objects More overhead since there's more likeliness of cache misses and actual reloads, but you can be sure any query will return the freshest value. - Extend retrieveObjectOf:json: to either replace doc refs with proxies, or do eager (recursive) lookup of whether cached versions of referenced documents are up-to-date when returning a cached object. In reality, only the first really makes sense; as you can never guarantee how long a queried object stays current. Cheers, Henry

Jan. 26, 2017

Re: [Pharo-users] [ANN] Pharo Sprint Friday, Jan 27

by Marcus Denker

> On 26 Jan 2017, at 14:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > (this is a bit lateâ¦ next will be announced earlier. I will start to put the sprints as official > events on the assoc site, too) https://association.pharo.org/event-2447196 <https://association.pharo.org/event-2447196> No idea if it makes sense to have them listed hereâ¦ Marcus

Jan. 26, 2017