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

Brea wiki software

by H. Hirzel

On 8/23/17, Offray <offray.luna(a)mutabit.com> wrote: > Hi, > > On the Teapot + Mustache integration, Hannes, you may want to see my early > prototype: > > http://smalltalkhub.com/#!/~Offray/Brea > > At some point, it will contain distributed wiki, backed by Fossil, now that > we're thinking in empower community driven wiki like documentation. > > Offray Hi Offray I found Name: Brea-OffrayLuna.8 Author: OffrayLuna Time: 1 June 2017, 4:18:20.860411 pm There is no test to show me how to use it and I none of the class comments of the 4 classes gives enough clues. Interesting method so far routes "I define how the website behaves accordingly to particular routes." self server serveStatic: 'demo' from: '/opt/gig/'; GET: 'members/test' -> [ :req | BreaMember new renderTestUserAsHtml ]; GET: 'members/add' -> [ :req | BreaMember new htmlInput ]; POST: 'members/summit' -> [ :req | self processNewMember: req ] May I ask you to give a few hints how to start it? Is it possible to use it without Fossil, just with image persistence? Regards Hannes

Aug. 23, 2017

Re: [Pharo-users] Where do I find a Pillar syntax summary?

by H. Hirzel

Found the (incomplete) list on the last slide of http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf so far. HH On 8/22/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Cyril > I imagine that you refer to link ref with *@...* > Yes we should probably produce a stylesheet. > > Now I'm busy finishing the new lecture. > > Since we could not reproduce the Pillar image for Pharo 40 (because of > a bug in metacello) luc > pushed the Pharo mooc to Pharo 50. > > Luc created a makefile producer from the pillar.conf and friday we will > do a day with damien on having the new makefile on all the booklets + > travis. > So that I can have one way to do things for all the project. > I want to deprecate all the postBuild.sh creation in all the projects. > > But lecture first > > Stef > > On Tue, Aug 22, 2017 at 12:56 PM, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com> wrote: >> Le 22/08/2017 Ã 09:25, H. Hirzel a Ã©crit : >>> Hello >>> >>> There is a tutorial for the Pillar document writing system [1]. The >>> Pharo 6 catalog entry shows that the Pillar syntax goes back to the >>> Pier CMS syntax of Lukas Renggli [2]. >>> >>> There is a syntax summary for the Pier CMS >>> >>> http://www.piercms.com/doc/syntax [3] >>> >>> I assume that most this still applies for Pillar? >>> But I can imagine that there have here been updates / changes / >>> extensions. >>> >>> I am looking for a Pillar syntax summary ("cheat sheet"). >>> Is this available somewhere? >>> >>> Kind regards >>> >>> Hannes >>> >>> >> >> Hi! >> >> For everything before 2015 there is this one: >> >> https://www.cheatography.com/benjaminvanryseghem/cheat-sheets/pillar/ >> >> But everything added after 2015 there is none :( Also there was a change >> of syntax on the links but I don't remember which one. The correct >> syntax should be in the PDF you referenced in [1]. >> >> I'll add an issue to the Pillar repo to create such a sheet but I will >> not have the time to do it. (At least not now) >> >>> >>> >>> [1] >>> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… >>> >>> [2] Pharo 6.1 catalog entry for Pillar >>> >>> Pillar is a wiki-like syntax, its document model, a parser for it, and >>> a set of exporters (e.g., HTML, LaTeX, Markdown...). Pillar is >>> primarily used as the wiki syntax behind the *Pier >>> CMS>http://piercms.com*. Pillar is also being used to write books: >>> e.g., *the Enterprise Pharo book>http://books.pharo.org/*. >>> >>> The original creator of Pillar (formerly known as ''the syntax behind >>> the Pier CMS'') is Lukas Renggli. Nevertheless, *Damien >>> Cassou>damien.cassou(a)inria.fr* is now the maintainer. The website is >>> at *http://www.smalltalkhub.com/#!/~Pier/Pillar*. Issues should be >>> reported to *https://github.com/pillar-markup/pillar/issues* >>> >>> >>> [3] http://wiki.squeak.org/squeak/3700 has some information about Pier. >>> It refers to a Smallwiki mailing list which is active. >>> >>> https://www.list.inf.unibe.ch/pipermail/smallwiki/ >>> >>> e.g. >>> https://www.list.inf.unibe.ch/pipermail/smallwiki/2016-November/008051.html >>> with an announcment 'Pier3 with latest Pillar' >>> >> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> > >

Aug. 23, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by bdurin

Hi Stef, Thank you for your explanations! About deprecation, I found it fast because I think FFI as a key component of a language. I imagine similar problems could happen when going from Morphic to its successor (Bloc?). Even with a stable API, I expect some code to explicitely depends on Morphic and break in the next GUI framework. I do not think this can be avoided. I am aware that maintenance is very costly and that it is always hard to be sure new users do not get caught in this kind of change. (As far as I understand the old MVC framework was kept quite long along with the at-the-time new Morphic to ensure smooth transition.) Note that I am not trying to claim that Pharo generally is bad or worse than another language. As a new user, my expectations were quite high after spending a few weeks learning the language, going through the MOOC, being able to tinker with the UI (looking at everything, modifying the World Menu, etc.), looking into the details of the bytecode and the VM. All of these worked very well and I still do think that Pharo is a great of software as I wrote in a previous question. Even when facing the UI problem in Pharo 5 due to old FFI syntax, I was able to hack into the code and get it work. In another language hitting an "internal" problem often is a dead end. I cannot tackle the problems I highlighted by myself. But with the help of someone who knows how to address them in the Pharo's way, I am willing to help. About dependencies and version, I knew of Metacello configurations when I wrote my first message and I was thinking of Pharo version (more precisely the versions of core packages and dependencies as opposed to other external packages that should be loaded on top of a freshly downloaded image). I did not know that Pharo version was in configurations. So I had a look at ConfigurationOfZeroMQ and maybe it keeps on being an exception but I did not find any dependency on Pharo version in it. However it declares a dependency on FFI version 1.4, which eventually is better than explicitely setting a dependency on a Pharo version. I also had a look at the "validate" class method and its comment that mentions "MetacelloMCVersionValidator". How is this validation mechanism triggered? I could work on it and modify the source code loader(s) so that instead of getting a syntax error in Pharo 6 I get an error or a critical warning from the validator. (I loaded the package by adding the corresponding repository in the Monticello browser and loading ZeroMQ and ConfigurationOfZeroMQ last versions.) I eventually found what you talked about. In ConfigurationOfFFI, "stable:" method lists the FFI versions that Pharo versions supports. The convention for versioning is not clear to me: old FFI is supposed to work up to Pharo 4 and the spec says FFI should be 1.7 to 1.9, which would mean that if a package needs version x, any version y>=x is ok, but from Pharo 5 (which requires FFI 1.10.1) it should fail, which would mean that version x should be matched exactly (or an interval should be defined). In Pharo 6 ConfigurationOfUnifiedFFI>>version_0_26_8 declares a dependency on FFI-Kernel âFFI-Kernel-EstebanLorenzano.45â, which I do not understand. Maybe here I can remove FFI dependencies. (Is this what you meant when saying you could have deprecated it but did not do it?) Besides ConfigurationOfFFI is not included in a freshly downloaded Pharo image (I checked for Pharo 5), I found a reference to it in ConfigurationOfUnifiedFFI (in the "ffi:" method) and manually added the corresponding repository (MetaRepoForPharo50) in Monticello browser and loaded the last version of ConfigurationOfFFI. So it seems that the info is not available by default. I had also a look at FFI-Kernel package (the object as found by running "RPackageOrganizer default packages select: [:p | p name = #'FFI-Kernelâ].") and could not find any version info. Is it correct that the version info of a package is only available through ConfigurationOf... and is not included in the package object? If I understand well, a way to correct the problem would be: - to ensure (or set it as an option for a start) that Metacello validation is triggered even when loading source code and let the user choose from an option whether it wants errors at loading stage or only warnings (and expect problems when running). - add all the ConfigurationOf that are in "Pharo/MetaRepoForPharo50/main" repository in the corresponding official image (maybe rather do this for Pharo60 which is still maintained) so that the validation gets all the needed info - as you mentioned in an earlier message ConfigurationOf for some "internal" packages (included in a freshly downloaded Pharo image) are missing, so add them, attribute them a version and set dependencies accordingly. (I can help, it is a good way to learn about the internals of the language.) Is it correct? (I can also work on the validator with some help.) About correcting the specific problem I had in Pharo 5. Esteban told me that it was not useful so I am confused now. About 0mq, I am not an expert of the (original) C library and of the python bindings. The library sets up sockets for communication between processes and even if you can serialize them apparently ZeroMQ is relatively brittle as regards initialization (and this is one of its flaws). The author of the ZeroMQ Pharo package was aware of the persistence problem and mentioned he could not solve it completely. This is not an easy problem apparently. About python bindings, they abstract initialization a bit and more importantly offer abstractions to process the messages through the sockets: integration with the async python 3 framework and with a popular event loop (python tornado library from Facebook) are offered. It is much easier to work with ZeroMQ this way as you do not have to care about low-level IO details. (I do not know how it is done in the python bindings but for example to listen to the socket either an event loop could take care of the regular polling of the sockets or one could set up a thread that listens to the socket through a blocking call.) The equivalent in Pharo might be to integrate ZeroMQ with the GUI event loop. (Not something I am able to do unfortunately.) Thanks, Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 23, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by bdurin

Hi Marcus, I would be happy to contribute to your experiment. Let me know. Bruno -- View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 23, 2017

Re: [Pharo-users] Teapot and Mustache in Pharo 6?

by Offray

Hi, On the Teapot + Mustache integration, Hannes, you may want to see my early prototype: http://smalltalkhub.com/#!/~Offray/Brea At some point, it will contain distributed wiki, backed by Fossil, now that we're thinking in empower community driven wiki like documentation. Offray El 21 de agosto de 2017 10:52:47 GMT-05:00, "H. Hirzel" <hannes.hirzel(a)gmail.com> escribiÃ³: >Hello > >The TeaPot documentation [1] references Mustache [2] in the section > > 4.1. Response Transformers [3] > >There is an example for a JSON transformation but none for Mustache. > >Where do I find some information how to use Mustache together with >Teapot? > >Regards >Hannes > > > > >[1] >https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > >[2] >https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > >[3] The responsibility of a response transformer is to convert the >output of the action block to HTML and to set the content-type of the >response. Some response transformers require external packages (e.g., >NeoJSON, STON, Mustache). > >[4] Adapted example > >TLWebserver teapot GET: '/jsonlist' -> #(1 2 3 4); output: #json. -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Aug. 23, 2017

Re: [Pharo-users] new chapter on double dispatch for new book :)

by Dimitris Chloupis

I read it once without knowing what double dispatch is, after reading it , I did not know what double dispatch is. It took several reads to understand what double dispatch is. My suggestion is starting with explaining as a summary what double dispatch is , instead of leaving it for the conclusion, explain not how it works but why we need it. Its a good idea to give a general picture to the reader before a practical example as a map to follow the example more easily and not be lost in the code. The code is easy to understand but the intention is not. Also what is a "die handle" ? On Wed, Aug 23, 2017 at 1:54 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > feedback is welcome > Good reading >

Aug. 23, 2017

new chapter on double dispatch for new book :)

by Stephane Ducasse

feedback is welcome Good reading

Aug. 23, 2017

Re: [Pharo-users] Minimizing an Application

by Dimitris Chloupis

Pharo desperately needs an image management tool. But in the end it will be up to the code hero that will decided the bite the bullet and do it. There are like a ton of things that can improve and a ton of potential ideas and projects, this is just one. It wont be easy though because code inside Pharo has the tendency to inter depend in some not so elegant ways. The fact that methods are so small and so many makes it hard to tell how uninstall a package will brake your image. I speak out of experience of actually trying this and corrupting the image (aka I was never to get the image to work again). Makes me wonder whether a solution would be to approach this in a "lazy kid cleans his room , by putting everything under his bed" kind of way. Create filters inside the System Browser that hide much of the mess and it make image seem far smaller and far simpler than it actual is. Of course its not an actual solution if you really want a reduced pharo image, but 10mbs which is the size pharo image can be reduced to is nothing for todays TBs hard drives and GBs flash drives and online storage. Unless you do an embedded app and 10 mbs are huge for your limited storage. On Wed, Aug 23, 2017 at 11:50 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We would like to have dll like deployment too. But I'm too dull to > know how to do implement it. > > Stef > > On Tue, Aug 22, 2017 at 2:17 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: > > VAST provided such image deployment tool, where you could save the > > deployment instructions, as whether to include/exclude certain > > packages, classes, methods, etc. It was great, although it wasn't > > "easy" to work with. > > > > Dolphin Smalltalk has an Image Stripper, that does something like > > that, but by "removing" stuff from a copy of the image, it worked > > really well in practice and was super easy to use. Also, you can > > decide what "SessionManager" will be used in the deployed image, for a > > normal development image, it is DevelopmentSessionManger, but for a > > web app it could be a CommandLineSessionManager, or if you have a GUI > > desktop app, it could be your own session manager class. > > > > But what I liked the most was VisualSmalltalk's SLL (Smalltalk's > > Linked Library), where you could "link" your application with true > > modules, that were binary. You explicitly specify its contents > > (classes, methods, pools, etc.) when building (compiling), and could > > be replaced without having to redeploy everything. It could lead to > > some dependency hell if done wrong, but not more than any other module > > solution. And they were very compact. > > > > In my Pharo deployments, since they are web applications, I always > > deployed the whole image in the server, built from a vanilla one, but > > without stripping anything. > > > > Regards, > > > > Esteban A. Maringolo > > > > > > 2017-08-22 0:22 GMT-03:00 Richard Sargent < > richard.sargent(a)gemtalksystems.com>: > >> VA Smalltalk doesn't strip an image; it builds a new image based on > >> application dependencies. With VA's packaging functionality, you are > more > >> likely to get a packaging error that reports you are trying to use > something > >> that isn't reachable according to the defined dependencies. > >> > >> I admit that except for the first few years, most of my early Smalltalk > >> experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer > it's > >> practice of building an image based on what you have told it to include. > >> > >> On Aug 21, 2017 15:22, "Tim Mackinnon" <tim(a)testit.works> wrote: > >>> > >>> There has been a lot of great work on this front on the Pharo side from > >>> the "team" and PharoLambda has made use of it (although it's a tiny > >>> project). > >>> > >>> My footprint is ~22mb including vm & image. And leaving out sources. > >>> > >>> The ./scripts directory has the example of how to do it, along side the > >>> .gitlab-ci.yml file. > >>> > >>> Unlike the commercial distributions (and this may have changed > recently), > >>> there is a minimal image you can have download, which has enough to > >>> bootstrap loading your project via metacello. There are no browser > tools or > >>> morphic things in the starting image I have chosen. > >>> > >>> You can potentially get smaller - but it's a decent result. The only > bit I > >>> added was to remove testcases (optional), and clear down metacello. > >>> > >>> It's probably worthy of a blog post - but honestly the running example > is > >>> pretty straight forward. > >>> > >>> The commercial tools all have a decent "strip dead code" tool, that > does a > >>> similar thing in reverse - which is equally a decent way of > approaching the > >>> problem and can lead to even tinier results. > >>> > >>> Tim > >>> > >>> Sent from my iPhone > >>> > >>> On 21 Aug 2017, at 21:25, horrido <horrido.hobbies(a)gmail.com> wrote: > >>> > >>> I received this comment on Facebook: > >>> > >>> Smalltalk is a fantastic language and its development environment > can't be > >>> beat... But the documentation for the many open source implementations > is > >>> contradictory or confusing or missing. I can't speak for the commercial > >>> versions. Without an experienced mentor it is not possible to create a > >>> complex app. And even when you have done so, *I know no way to strip > out > >>> the > >>> unused part of the image as well as the embedded source code*. > >>> ----- > >>> > >>> This issue of stripping out unused code seems to recur a lot. And > truth be > >>> told, I've never seen a clear explanation of how to do this. Can > someone > >>> provide clear direction? Is this documented anywhere? I'd like to use > the > >>> information in future to assuage other people's concerns. > >>> > >>> Thanks. > >>> > >>> > >>> > >>> -- > >>> View this message in context: > >>> http://forum.world.st/Minimizing-an-Application-tp4963262.html > >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >>> > >> > > > >

Aug. 23, 2017

Re: [Pharo-users] Glorp: Is there some way to do insert-or-update?

by Herby VojÄÃk

jtuchel wrote: > Herby, > > as Esteban already said, UPSERT doesn't make any sense in an ORM. It I don't know... I just create new object (with same "primary key") and register it (yes, I know I get an error - maybe I should be able to set the policy to "overwrite" and it would makes sense; or not?). > either knows the object as one that has been read in this session or > not. If not, it is new and needs to be inserted. > > You could, of course, try and see what happens if you let Glorp's insert > operation always issue an UPSERT. This is probably very easy to do and > at first sight there isn't too much I could think of that could go wrong > with it. > > But I guess including a check for existence of an object as Esteban > suggests isn't too bad from the performance and "safety" POV. not sure I > understand how a Dictionary Mapping could help here.... Similarly to what was posted above: I can simply at:put: and I don't care if I created the new key-value pair or overwritten the old value (in cases where simply putting new object under a key is feasible, which is in this case). > Joachim Herby > Am Dienstag, 22. August 2017 12:13:30 UTC+2 schrieb Herbert VojÄÃk: > > Hello! > > Is there some way to do insert-or-update operation (that is, > roughly, to > be able to register an object with possibly existing primary key(s) and > let it be written regardless? > > Thanks, Herby > > P.S.: Use case - I want to have log of USER-DEVICE pairing with last > timestamp and 'enabled' field that would be set to false once push > notification fails - but set to true once user actually logs from the > device (again). I don't want to have many historical records, so I want > to have USER+DEVICE to be a composed primary key. Which means it is > inserted first time, but possibly updated later. > > -- > You received this message because you are subscribed to the Google > Groups "glorp-group" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to glorp-group+unsubscribe(a)googlegroups.com > <mailto:glorp-group+unsubscribe@googlegroups.com>. > To post to this group, send email to glorp-group(a)googlegroups.com > <mailto:glorp-group@googlegroups.com>. > Visit this group at https://groups.google.com/group/glorp-group. > For more options, visit https://groups.google.com/d/optout.

Aug. 23, 2017

Re: [Pharo-users] Minimizing an Application

by Stephane Ducasse

We would like to have dll like deployment too. But I'm too dull to know how to do implement it. Stef On Tue, Aug 22, 2017 at 2:17 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > VAST provided such image deployment tool, where you could save the > deployment instructions, as whether to include/exclude certain > packages, classes, methods, etc. It was great, although it wasn't > "easy" to work with. > > Dolphin Smalltalk has an Image Stripper, that does something like > that, but by "removing" stuff from a copy of the image, it worked > really well in practice and was super easy to use. Also, you can > decide what "SessionManager" will be used in the deployed image, for a > normal development image, it is DevelopmentSessionManger, but for a > web app it could be a CommandLineSessionManager, or if you have a GUI > desktop app, it could be your own session manager class. > > But what I liked the most was VisualSmalltalk's SLL (Smalltalk's > Linked Library), where you could "link" your application with true > modules, that were binary. You explicitly specify its contents > (classes, methods, pools, etc.) when building (compiling), and could > be replaced without having to redeploy everything. It could lead to > some dependency hell if done wrong, but not more than any other module > solution. And they were very compact. > > In my Pharo deployments, since they are web applications, I always > deployed the whole image in the server, built from a vanilla one, but > without stripping anything. > > Regards, > > Esteban A. Maringolo > > > 2017-08-22 0:22 GMT-03:00 Richard Sargent <richard.sargent(a)gemtalksystems.com>: >> VA Smalltalk doesn't strip an image; it builds a new image based on >> application dependencies. With VA's packaging functionality, you are more >> likely to get a packaging error that reports you are trying to use something >> that isn't reachable according to the defined dependencies. >> >> I admit that except for the first few years, most of my early Smalltalk >> experience involved ENVY and VA/VisualAge Smalltalk. Still, I prefer it's >> practice of building an image based on what you have told it to include. >> >> On Aug 21, 2017 15:22, "Tim Mackinnon" <tim(a)testit.works> wrote: >>> >>> There has been a lot of great work on this front on the Pharo side from >>> the "team" and PharoLambda has made use of it (although it's a tiny >>> project). >>> >>> My footprint is ~22mb including vm & image. And leaving out sources. >>> >>> The ./scripts directory has the example of how to do it, along side the >>> .gitlab-ci.yml file. >>> >>> Unlike the commercial distributions (and this may have changed recently), >>> there is a minimal image you can have download, which has enough to >>> bootstrap loading your project via metacello. There are no browser tools or >>> morphic things in the starting image I have chosen. >>> >>> You can potentially get smaller - but it's a decent result. The only bit I >>> added was to remove testcases (optional), and clear down metacello. >>> >>> It's probably worthy of a blog post - but honestly the running example is >>> pretty straight forward. >>> >>> The commercial tools all have a decent "strip dead code" tool, that does a >>> similar thing in reverse - which is equally a decent way of approaching the >>> problem and can lead to even tinier results. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 21 Aug 2017, at 21:25, horrido <horrido.hobbies(a)gmail.com> wrote: >>> >>> I received this comment on Facebook: >>> >>> Smalltalk is a fantastic language and its development environment can't be >>> beat... But the documentation for the many open source implementations is >>> contradictory or confusing or missing. I can't speak for the commercial >>> versions. Without an experienced mentor it is not possible to create a >>> complex app. And even when you have done so, *I know no way to strip out >>> the >>> unused part of the image as well as the embedded source code*. >>> ----- >>> >>> This issue of stripping out unused code seems to recur a lot. And truth be >>> told, I've never seen a clear explanation of how to do this. Can someone >>> provide clear direction? Is this documented anywhere? I'd like to use the >>> information in future to assuage other people's concerns. >>> >>> Thanks. >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Minimizing-an-Application-tp4963262.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >> >

Aug. 23, 2017