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

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

by Stephane Ducasse

Hi in fact I was wrong we do not support pragma for FFI and we could have deprecated them but we did not. Stef On Tue, Aug 22, 2017 at 5:15 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx for the report > > > On Wed, Aug 16, 2017 at 11:31 PM, bdurin <bruno.durin(a)gmail.com> wrote: >> Hi, >> >> I stumbled upon what seems to me a strange issue in Pharo 5. The RBParser >> fails to correctly parse the legacy FFI pragmas. This completely breaks down >> the browser, the inspector and debugger (because as far as I understand all >> use RBParser to correctly highlight syntax). I had the image crashed and >> some red boxes at some point while insisting to inspect and debug. Overall >> this is not a big issue but it raises some more general bells to me. >> >> In order to reproduce this: >> - load the official Pharo 5 (curl get.pharo.org/50+vm | bash) >> - launch the image (./pharo-ui Pharo.image &) >> - add the following repository >> MCSmalltalkhubRepository >> owner: 'panuw' >> project: 'zeromq' >> user: '' >> password: '' >> - load the last versions of ZeroMQ and ConfigurationOfZeroMQ (not sure if >> the latter is needed) >> - open a Nautilus Browser and look at the class method apiZmqBind:to: of the >> ZmqApi class in the ZeroMQ package: you get a MessageNotUnderstood error >> (receiver of keywords is nil). You can get past this by clicking on >> "Abandon" but the source code is displayed in a corrupted way: >> apiZmqBind: s >> ocket to: endpoint <cdecl >> - repeat a few times by looking at other methods until you get a red box: >> then you cannot look at source code any more with this browser. If you are >> obstinate and "lucky" you will succeed in crashing the image. >> - you can pin the problem by running in a Playground >> RBParser parseFaultyMethod: 'apiZmqBind: socket to: endpoint >> <cdecl: long ''zmq_bind'' (ZmqApiSocket* char*) module:''zmq''> >> ^self externalCallFailed'. >> and you'll see that the pragmas is not correctly parsed. (The root cause is >> that the legacy adapter RBFFICallPragma does not follow the API defined by >> its super class RBPragmaNode (selector, arguments, positions) and so is not >> a properly defined node. I corrected the problem by computing and setting >> the corresponding instance variables.) > > > >> 1) As a beginner at Pharo, I find it difficult to deal with the various >> versions of Pharo. ZeroMQ is the (only) Smalltalk-Pharo binding for zmq. It >> dates back to Feb 2014 so I expected it to work in Pharo as of 3 years and a >> half later (Pharo 6 dates back to June 2017). > > We maintain actively 2 versions on 5 OSes. > On many system old libraries do not work on new versions. > By definition I never believe that a version of Mac OS 9 is working on > Mac OS 11 and Mac has a lot of money. > A lot more than us. > > >> I naively tried to load the package in a Pharo 6 image and it failed because >> of a syntax error. As I had read a lot about the various FFI mechanisms, I >> quickly understood that it must be because the FFI declarations in pragma >> are not supported anymore. > > They still are but you probably hit an edge case. > >> I then loaded the package in a Pharo 5 image and I got the error that I >> described. After finding the error and solving it, I guess that the FFI >> declaration in pragma was barely supported in Pharo 5, which has already >> switched to UFFI and that it is something dating back to Pharo 4. (I did not >> try with Pharo 4 as I do not want to work with versions before 5). > > Normally we took care to be backward compatible to ease moving from > one version to the other > one. Esteban was on vacation and I asked him to have a look. > > >> Is there a way to know for a package what the compatible Pharo version is? >> It seems that currently I have to look at dates, look at the features used >> by the package and look for the history of development (fortunately the >> mailing lists are easy to search) to understand which version is likely to >> work. > > People should > - publish their package in the catalog of a given version. > - have test > - have a configuration because this configuration list also the > version of Pharo. > > >> Are not deprecations a bit too fast if a package written 3 years ago cannot >> work in the latest Pharo version and trigger bugs in Pharo 5, which dates >> back to May 2016 (so only a bit more than 2 years after)? > > This is not a deprecation. This is probably just a case that was not handle. > We spent 8 months developing a new FFI and there is still points to be added. > >> I find it a bit too fast as compared to mainstream languages. To my mind, >> either deprecations should be slower or a version/dependencies system should >> be there to help users. > > Please do not generalise from one case. > We pay attention to make sure that people can move. Now > >> >> 2) Another question about versions: Pharo 6 is out since June, Pharo 7 is >> under development. What is the status of Pharo 5? Already history or still >> relevant? > > We do not actively back port fix to Pharo 50. But you can execute > Pharo 50 and we build regularly vms. > > > >> I am asking because I corrected the problem of FFI declaration in pragma, >> but it seems to me that it is not useful to publish this change as starting >> from Pharo 6 this way to do FFI is not supported. So should I contribute? > > Please send your fixes so that we can have a look at it. > >> yes, how to "attach" the patch to Pharo 5? > > You can > - open a bug entry and publish a slice in the Pharo50Inbox > - fileout your changes and send them to the mailing-list to start with. > > >> >> 3) As explained above, in Pharo 5, looking at the source trigger an error. >> Even if this looks like a rare corner case, I think that the developer tools >> should not trigger bugs when looking at source code, even less trigger a red >> box in the source code viewer (in the browser, but the problem also occurs >> --less strongly-- when looking at the object in an inspector: there should >> not be "error printing" when it is only a syntax highlight problem). If the >> code is malformed and the parser used to highlight syntax fails, there >> should be a fallback such as the source code being displayed without any >> highlight. It sends a very bad impression to have this kind of bugs when one >> simply wants to look at code, not even running it. > > Yes you are correct. > > >> I have not dug enough in this area of Pharo, but it seems to me that the >> parser that is used to build the AST for code execution / method compilation >> should not be the same as the parser used to highligh syntax. (Of course I >> am not saying that there should be 2 distincts code base for the 2 parsers, >> but they should at least run differently.) The first one must be strict with >> errors as a malformed AST cannot be executed. The second one must be >> lenient, as a malformed AST does not prevent to print the string of the >> source code. Of course, at the end if the code is malformed there will be an >> error at execution, but if the source code can be displayed even when it is >> malformed, at least I have the opportunity to correct it so that it runs >> correctly. (In this case, convert the old FFI pragma declaration into a >> fficall:) > > This is more than that. > A parser error should not blow up the UI. This is a problem in the > current architecture. > Pharo is not perfect but we are working on it. > > >> I may be missing something here but if this works the same in the most >> up-to-date version of Pharo, the same kind of error might appear again. >> What do you think? > > We have a long list of improvements that we should do. > Pharo is not perfect. It is what we have now and that we use daily, > improve daily > but developing robust and good quality software is taking a lot of time. > We have to prioritize for each version. > Now we make progress. Each version of Pharo is getting better. > > >> >> 4) A final remark: let us classify people as Beginner/Confirmed in >> programming and B/C in Pharo (A BB is a beginner in programming and in >> Pharo, a CC confirmed in both, a BC cannot exists and CB are those who >> discover Pharo while knowing well other languages). Pharo seems to be great >> for BB and CC. I went through the MOOC and the various books which are >> great. My first steps in Pharo environment were great. >> As a CC it seems to be great also as in the very small area of the system >> where I took the time to drill into all the details, I could very easily >> change things (and correct a bug), that would have been very difficult to >> understand and change in a lot of other languages. Even hacking the VM seems >> to be possible for a non-VM expert. >> But I consider myself rather as a CB. As such I tend to try and do complex >> things that I usually do in other languages and run into tricky problems. >> These problems are rather dealt with and corrected by Pharo developers but >> that as a user I would expect them to remain hidden to me or to be clearly >> advertised in the docs. As compared to a BB, a CB is not going to stay in a >> well delimited area where everything is smooth. >> True, in a way it is a very strong incentive to become a Pharo expert! But I >> am wondering if this aspect could be improved. > > Freedom of action is a two edge sword. > We are concerned by that aspect. Now often it is not easily to hide > and reveal on demand > a reflective system. > > Stef > > >> >> 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. 22, 2017

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

by Stephane Ducasse

Tx for the report On Wed, Aug 16, 2017 at 11:31 PM, bdurin <bruno.durin(a)gmail.com> wrote: > Hi, > > I stumbled upon what seems to me a strange issue in Pharo 5. The RBParser > fails to correctly parse the legacy FFI pragmas. This completely breaks down > the browser, the inspector and debugger (because as far as I understand all > use RBParser to correctly highlight syntax). I had the image crashed and > some red boxes at some point while insisting to inspect and debug. Overall > this is not a big issue but it raises some more general bells to me. > > In order to reproduce this: > - load the official Pharo 5 (curl get.pharo.org/50+vm | bash) > - launch the image (./pharo-ui Pharo.image &) > - add the following repository > MCSmalltalkhubRepository > owner: 'panuw' > project: 'zeromq' > user: '' > password: '' > - load the last versions of ZeroMQ and ConfigurationOfZeroMQ (not sure if > the latter is needed) > - open a Nautilus Browser and look at the class method apiZmqBind:to: of the > ZmqApi class in the ZeroMQ package: you get a MessageNotUnderstood error > (receiver of keywords is nil). You can get past this by clicking on > "Abandon" but the source code is displayed in a corrupted way: > apiZmqBind: s > ocket to: endpoint <cdecl > - repeat a few times by looking at other methods until you get a red box: > then you cannot look at source code any more with this browser. If you are > obstinate and "lucky" you will succeed in crashing the image. > - you can pin the problem by running in a Playground > RBParser parseFaultyMethod: 'apiZmqBind: socket to: endpoint > <cdecl: long ''zmq_bind'' (ZmqApiSocket* char*) module:''zmq''> > ^self externalCallFailed'. > and you'll see that the pragmas is not correctly parsed. (The root cause is > that the legacy adapter RBFFICallPragma does not follow the API defined by > its super class RBPragmaNode (selector, arguments, positions) and so is not > a properly defined node. I corrected the problem by computing and setting > the corresponding instance variables.) > 1) As a beginner at Pharo, I find it difficult to deal with the various > versions of Pharo. ZeroMQ is the (only) Smalltalk-Pharo binding for zmq. It > dates back to Feb 2014 so I expected it to work in Pharo as of 3 years and a > half later (Pharo 6 dates back to June 2017). We maintain actively 2 versions on 5 OSes. On many system old libraries do not work on new versions. By definition I never believe that a version of Mac OS 9 is working on Mac OS 11 and Mac has a lot of money. A lot more than us. > I naively tried to load the package in a Pharo 6 image and it failed because > of a syntax error. As I had read a lot about the various FFI mechanisms, I > quickly understood that it must be because the FFI declarations in pragma > are not supported anymore. They still are but you probably hit an edge case. > I then loaded the package in a Pharo 5 image and I got the error that I > described. After finding the error and solving it, I guess that the FFI > declaration in pragma was barely supported in Pharo 5, which has already > switched to UFFI and that it is something dating back to Pharo 4. (I did not > try with Pharo 4 as I do not want to work with versions before 5). Normally we took care to be backward compatible to ease moving from one version to the other one. Esteban was on vacation and I asked him to have a look. > Is there a way to know for a package what the compatible Pharo version is? > It seems that currently I have to look at dates, look at the features used > by the package and look for the history of development (fortunately the > mailing lists are easy to search) to understand which version is likely to > work. People should - publish their package in the catalog of a given version. - have test - have a configuration because this configuration list also the version of Pharo. > Are not deprecations a bit too fast if a package written 3 years ago cannot > work in the latest Pharo version and trigger bugs in Pharo 5, which dates > back to May 2016 (so only a bit more than 2 years after)? This is not a deprecation. This is probably just a case that was not handle. We spent 8 months developing a new FFI and there is still points to be added. > I find it a bit too fast as compared to mainstream languages. To my mind, > either deprecations should be slower or a version/dependencies system should > be there to help users. Please do not generalise from one case. We pay attention to make sure that people can move. Now > > 2) Another question about versions: Pharo 6 is out since June, Pharo 7 is > under development. What is the status of Pharo 5? Already history or still > relevant? We do not actively back port fix to Pharo 50. But you can execute Pharo 50 and we build regularly vms. > I am asking because I corrected the problem of FFI declaration in pragma, > but it seems to me that it is not useful to publish this change as starting > from Pharo 6 this way to do FFI is not supported. So should I contribute? Please send your fixes so that we can have a look at it. > yes, how to "attach" the patch to Pharo 5? You can - open a bug entry and publish a slice in the Pharo50Inbox - fileout your changes and send them to the mailing-list to start with. > > 3) As explained above, in Pharo 5, looking at the source trigger an error. > Even if this looks like a rare corner case, I think that the developer tools > should not trigger bugs when looking at source code, even less trigger a red > box in the source code viewer (in the browser, but the problem also occurs > --less strongly-- when looking at the object in an inspector: there should > not be "error printing" when it is only a syntax highlight problem). If the > code is malformed and the parser used to highlight syntax fails, there > should be a fallback such as the source code being displayed without any > highlight. It sends a very bad impression to have this kind of bugs when one > simply wants to look at code, not even running it. Yes you are correct. > I have not dug enough in this area of Pharo, but it seems to me that the > parser that is used to build the AST for code execution / method compilation > should not be the same as the parser used to highligh syntax. (Of course I > am not saying that there should be 2 distincts code base for the 2 parsers, > but they should at least run differently.) The first one must be strict with > errors as a malformed AST cannot be executed. The second one must be > lenient, as a malformed AST does not prevent to print the string of the > source code. Of course, at the end if the code is malformed there will be an > error at execution, but if the source code can be displayed even when it is > malformed, at least I have the opportunity to correct it so that it runs > correctly. (In this case, convert the old FFI pragma declaration into a > fficall:) This is more than that. A parser error should not blow up the UI. This is a problem in the current architecture. Pharo is not perfect but we are working on it. > I may be missing something here but if this works the same in the most > up-to-date version of Pharo, the same kind of error might appear again. > What do you think? We have a long list of improvements that we should do. Pharo is not perfect. It is what we have now and that we use daily, improve daily but developing robust and good quality software is taking a lot of time. We have to prioritize for each version. Now we make progress. Each version of Pharo is getting better. > > 4) A final remark: let us classify people as Beginner/Confirmed in > programming and B/C in Pharo (A BB is a beginner in programming and in > Pharo, a CC confirmed in both, a BC cannot exists and CB are those who > discover Pharo while knowing well other languages). Pharo seems to be great > for BB and CC. I went through the MOOC and the various books which are > great. My first steps in Pharo environment were great. > As a CC it seems to be great also as in the very small area of the system > where I took the time to drill into all the details, I could very easily > change things (and correct a bug), that would have been very difficult to > understand and change in a lot of other languages. Even hacking the VM seems > to be possible for a non-VM expert. > But I consider myself rather as a CB. As such I tend to try and do complex > things that I usually do in other languages and run into tricky problems. > These problems are rather dealt with and corrected by Pharo developers but > that as a user I would expect them to remain hidden to me or to be clearly > advertised in the docs. As compared to a BB, a CB is not going to stay in a > well delimited area where everything is smooth. > True, in a way it is a very strong incentive to become a Pharo expert! But I > am wondering if this aspect could be improved. Freedom of action is a two edge sword. We are concerned by that aspect. Now often it is not easily to hide and reveal on demand a reflective system. Stef > > 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. 22, 2017

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

by Marcus Denker

> > On Tue, Aug 22, 2017 at 4:35 PM, bdurin <bruno.durin(a)gmail.com> wrote: >> Hi Hannes, >> >> Thanks for your help! I agree that loading in Pharo 4 (I guess) and >> following your recipe works and is easy. >> My concern is not specific to ZeroMQ though. In fact I discovered that >> ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I >> thought it was something more like the python bindings of 0mq that provides >> higher-level abstractions that are more useful. Besides the problem of >> persisting the state of a 0mq application in the image is quite hard to >> solve (and this was noted by the author of the Zeromq package). So I >> probably shall go with python this time. >> Beyond the specific problem of Zeromq package, I think there is something >> inconsistent in trying to develop Smalltalk/Pharo as a self-contained >> environment and not being able to load old code. In other languages, text >> editor or IDE are external tools but they usually open any source code. >> (That is why the title of my note is "Parser failure on FFI pragmas >> declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) >> I also wanted to point out that for people that are used to programming and >> as such could rapidly wander in corner areas of the language, I felt a tool >> / a procedure to manage dependencies and versions was missing. I am working on and off on an experiment to allow to load (and compile!) syntactically wrong code. (the idea is that it compiles a runtime error what would normally be a static syntax error, this is available by turning on the "Allow code with syntax errorsâ Setting). This might not solve the FFI problem (need to look at that), but it will make loading strange code easierâ¦ Marcus

Aug. 22, 2017

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

by Stephane Ducasse

Bruno There was a huge change in the FFI (in fact it was rewritten from the ground) and you face a case where we were not backward compatible. Nobody reported it to us before. Now if you unzip the mcz you get the pharo text in plain mode. It does not solve the problem of parsing but in that case you are exactly in the same situation than other languages or I did not understand your problem. We are managing version and dependencies since years :) luckily. The part that is missing is that every package loaded in the pharo image cannot be used as dependent for external packages because of lack of metadata. We are working on having metadata for any package (being inside Pharo or external). I do not know what is used in ZeroMQ. Now two questions: - what are the abstractions that the python binding offers? - what is the state of a 0mq application? Because we can serialise and reload execution stack. So the only things that we cannot serialize are active process so far. Stef On Tue, Aug 22, 2017 at 4:35 PM, bdurin <bruno.durin(a)gmail.com> wrote: > Hi Hannes, > > Thanks for your help! I agree that loading in Pharo 4 (I guess) and > following your recipe works and is easy. > My concern is not specific to ZeroMQ though. In fact I discovered that > ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I > thought it was something more like the python bindings of 0mq that provides > higher-level abstractions that are more useful. Besides the problem of > persisting the state of a 0mq application in the image is quite hard to > solve (and this was noted by the author of the Zeromq package). So I > probably shall go with python this time. > Beyond the specific problem of Zeromq package, I think there is something > inconsistent in trying to develop Smalltalk/Pharo as a self-contained > environment and not being able to load old code. In other languages, text > editor or IDE are external tools but they usually open any source code. > (That is why the title of my note is "Parser failure on FFI pragmas > declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) > I also wanted to point out that for people that are used to programming and > as such could rapidly wander in corner areas of the language, I felt a tool > / a procedure to manage dependencies and versions was missing. > > Regards, > 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. 22, 2017

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

by bdurin

Hi Hannes, Thanks for your help! I agree that loading in Pharo 4 (I guess) and following your recipe works and is easy. My concern is not specific to ZeroMQ though. In fact I discovered that ZeroMQ package is just a very low-level bindings of Zeromq C API whereas I thought it was something more like the python bindings of 0mq that provides higher-level abstractions that are more useful. Besides the problem of persisting the state of a 0mq application in the image is quite hard to solve (and this was noted by the author of the Zeromq package). So I probably shall go with python this time. Beyond the specific problem of Zeromq package, I think there is something inconsistent in trying to develop Smalltalk/Pharo as a self-contained environment and not being able to load old code. In other languages, text editor or IDE are external tools but they usually open any source code. (That is why the title of my note is "Parser failure on FFI pragmas declaration in Pharo 5" and not "Cannot load ZeroMQ package source code".) I also wanted to point out that for people that are used to programming and as such could rapidly wander in corner areas of the language, I felt a tool / a procedure to manage dependencies and versions was missing. Regards, 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. 22, 2017

Re: [Pharo-users] Minimizing an Application

by Esteban A. Maringolo

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. 22, 2017

Re: [Pharo-users] [Pharo-dev] TechTalk Dates for the rest of 2017

by Marcus Denker

> On 22 Aug 2017, at 13:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> I'm not sure Pharo tech talk is the good place but would love to see such a presentation. >>> >> Why not? I am sure Alex will have some code in there.. " programming, from scratch, a small artificial intelligenceâ >> if done with Pharo would be a very nice thing todo for the tech talk. > > Yes, that is the plan. It could be a very practical lecture, with a lot of coding (but not many lines of code). > I added it for October 17th: https://association.pharo.org/event-2642664 Marcus

Aug. 22, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Marcus Denker

> On 18 Aug 2017, at 09:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> What I think would have been good is to list all the updates that where done between >> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they were already >> in the image that you got a minute before Pharo6.1 was released, as they where released as >> hot fixes before). >> > > The changelog of things done between releasing 6.0 and the release of 6.1: > I added a link to the complete changeling to http://pharo.org/news/pharo6.1-released <http://pharo.org/news/pharo6.1-released> Marcus

Aug. 22, 2017

Re: [Pharo-users] [Pillar] Installed the Pillar document preparation system into 6.1, how do I start using it?

by Stephane Ducasse

Yes we need input (but most importantly time). I will allocate time because Pillar is important for me. On Fri, Aug 18, 2017 at 10:18 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On ven. 18 aoÃ»t 2017 at 22:09, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> Exactly. >> >> Section 7 of >> >> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… >> >> has an example >> >> >> | wiki | >> wiki := '!My Document'. >> PRPillarParser parse: wiki >> >> >> Or >> >> PRPillarParser parse: (FileSystem workingDirectory / 'foo.pillar') >> readStream >> >> >> and then >> >> >> PRHTMLWriter write: document >> >> >> This put together gives >> >> PRHTMLWriter write: ( >> PRPillarParser parse: (FileSystem workingDirectory / >> 'welcome.pillar') >> ) >> >> >> If I inspect the result of this expression I get the HTML string. >> >> Thank you Cyril. This is what I was looking for. >> >> --Hannes > > > > Happy to see it still works :) > > I know there was work on Pillar after I wrote this. Maybe there is some > functionalities that will need more than those simple examples. By I am not > sure and I know that Stephane want to simplify it further. > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France

Aug. 22, 2017

Re: [Pharo-users] YAML parser (2017)

by Stephane Ducasse

Hi Hannes you should report this to doru. Stef On Sat, Aug 19, 2017 at 8:36 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 8/19/17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> On Sat, Aug 19, 2017 at 02:45:28PM +0200, H. Hirzel wrote: >>> Peter, thanks for the confirmation that in your installation of the >>> PetitYAML grammar all tests are green. >>> >>> I wonder how you did it. >> >> As I've said, you need to update PetitParser; if there's no appropriate >> catalog entry, then ConfigurationOfPetitParser loadBleeding edge, or >> manually via Monticello Browser (the same way you loaded PetitYAML). >> >> Peter > > Thanks, loading ConfigurationOfPetitParser-TudorGirba.80 through the > Monticello Browser (not the catalog) into Pharo 6 and then > > ConfigurationOfPetitParser load > > did the job. Now all PetitYAML grammar tests are grenen. > > --Hannes

Aug. 22, 2017