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

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by jtuchel＠objektfabrik.de

Herby, I cannot say anaything good or bad about Garage, since I am not using Pharo regularly. Glorp is maintained by CIncom employees and Cincom uses Glorp for their source control management, so at least from a bug fixing perspective, Glorp is in good shape. It does lack features like multiple inheritance levels spread over tables, and it seems nobody is implementing that. So I would probably be careful about the brightness level of Glorp's future when it comes to new features. Not sure if and how the Pharo crowd is involved and whether Cincom is looking for help with Glorp. I know that Niall is very helpful and helps as good as he can (and he can) if time permits. I have been using Glorp on a commercial web project for years now and happy with it. But I am using it on another Smalltalk dialect. Glorp has been in a very poor shape on Pharo for a while, but about a year or two ago, it has re-gained traction. So if you want to use an O/R mapper in Smalltalk, I don't think there is anything maintained better than Glorp. It's as good as you can get in the Smalltalk world. Most alternatives are far less finished and look quite abandoned to me. So it seems like you need to swallow and make the best out of it ;-) Maybe somebody more deeply involved with Pharo has another (better?) option in their sleeves...? IIRC, Sven, who usually writes great code and maintains it very well, came up with a Postgres driver and a Glorp layer for it just a few weeks ago. If Garage doesn't work for you, and if Postgres is an option for you, you should definitiely take a look at it: https://github.com/svenvc/P3 HTH Joachim Am 14.08.17 um 11:57 schrieb Herby VojÄÃk: > Hello! > > Without wanting to offend anyone, I'd like to know, as I do not follow > the tides yet, what is the state of Glorp and Garage re maintained / > having bright future vs. stalled? > > I know about Voyage but I chose not to use it as it seems a bit > "savage" to me with automatically applying to all instances of a > class. Did I backed the right horse by using Glorp (and wanting to use > Garage drivers)? > > Thanks, Herby > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by Guillermo Polito

Hi Holger, Garage is not maintained as people started developing the alternative UDBC drivers, that share the same spirit at the end. I do not know if they share the same API though. About Glorp, I will let Esteban Maringolo ask :). On the other side, you should check again how you downloaded Garage and GarageGlorp because I still believe you're not using the latest versions. The last thing I did on that was to update it to pharo 6 and UFFI, so it is working. Moreover, I moved garage's code base to github to use travis (because inria CI was very unstable). https://github.com/guillep/garage/blob/master/.travis.yml And travis reports that last build on pharo 6 was green (at the time I set that up, travis had no cron jobs, so it was the last commit). https://travis-ci.org/guillep/garage So, Garage works on pharo 6 using UFFI, but I cannot maintain it mainly because I don't use relational databases on my daily work. Thus, this is complicated to maintain 4 backends for 3 platforms, on 2 pharo versions, if you don't eat your own food. Now, documentation may be outdated :) On Mon, Aug 14, 2017 at 11:57 AM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Hello! > > Without wanting to offend anyone, I'd like to know, as I do not follow the > tides yet, what is the state of Glorp and Garage re maintained / having > bright future vs. stalled? > > I know about Voyage but I chose not to use it as it seems a bit "savage" > to me with automatically applying to all instances of a class. Did I backed > the right horse by using Glorp (and wanting to use Garage drivers)? > > Thanks, Herby > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Honest question, new to ecosystem: are Glorp and Garage alive?

by Herby VojÄÃk

Hello! Without wanting to offend anyone, I'd like to know, as I do not follow the tides yet, what is the state of Glorp and Garage re maintained / having bright future vs. stalled? I know about Voyage but I chose not to use it as it seems a bit "savage" to me with automatically applying to all instances of a class. Did I backed the right horse by using Glorp (and wanting to use Garage drivers)? Thanks, Herby

Aug. 14, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

In a full image (just bootstrapped) we have: 7.7 MB of arrays (probably in collections, we should check usages) 6.3 MB of methods 5.3 MB of ByteArrays 3.3 MB of ByteStrings 2.7 MB of Bitmaps 1.8 MB of ByteSymbols That sumps up aready ~27 MB On Mon, Aug 14, 2017 at 11:49 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi Tim, > > On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hey guys, thanks for your enthusiasm around this - and I cannot stress >> enough how this was only possible because of the work that has gone into >> making Pharo (in particular the 64bit image, as well as having a minimal >> image, and some great blog posts on serialising contexts) as well as the >> patience from everyone in answering questions and helping me get it all >> working. >> >> Iâm still quite keen to get my execution time back down under 800ms and >> Iâd like to actually get back to writing a few skills to automate a few >> things around my house. >> >> To Answer Denisâ question - >> >> My final footprint is 30.4mb - thats composed of a 22mb image (with a >> simple example that pulls in Fuel, ZTimestamp and the S3 Library which >> depends on XMLParser) and then the VM (from which I removed obvious dllâs). >> >> In my original experiments with a 6.0 minimal image - I did manage to get >> to a 13.4mb image (which started out as 12mb original size, and then loaded >> in STON and had only a simple clock example). I think the sweet spot is >> around 20mb total footprint as that seems to get me into the 450ms-900ms >> range. >> >> The 7.0 min image now starts out at 15mb and then Iâm not sure why >> loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not >> dug into that). >> > > You can do further space analysis using the following expression > > SpaceTally new printSpaceAnalysis > > You can do that in an eval and check what's taking space. With measures we > can iterate and improve :). > > >> Iâve also found (and this on the back of unserialising the context in my >> example) that the way we build images has 15+ saved stack sessions that >> have saved on top of each other from the way we build up the images. I >> donât yet know the implications of size/speed of these - but we need a >> better way of folding executions when we snapshot headless images. Iâm also >> not clear if there are any other startup tasks that take precious time >> (this also has implications for our fat development images as they take >> much longer to appear than they really should). >> > > I'm working on this as I'm writing this mail ;) > > https://pharo.fogbugz.com/f/cases/20309 > https://github.com/pharo-project/pharo/pull/196 > > I'll write down the implications further in a different thread. > > >> Iâll be exploring some of these size/speed tradeoffâs in follow on >> messages. >> >> But once again, a big thanks - Iâve not enjoyed programming like this for >> ages. >> >> Tim >> >> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: >> >> hi Tim, >> >> That is..... AWESOME! >> >> Very nice delivery - it flowed well with great narration. >> >> I loved @2:17 "this is the interesting piece, because PharoLambda has >> serialized the execution context of its application and saved it into [my >> S3 bucket] ... [then on the local machine] rematerializes a debugger [on >> that context]." >> >> There is a clarity in your video presentation that really may intrigue >> outsiders. As a community we should push this on the usual hacker forums - >> ycombinator could be a good starting point (but I'm locked out of my >> account there). >> An enticing title could be... >> "Debugging Lambdas by re-materializing saved execution contexts on your >> local machine." >> >> cheers -ben >> >> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> This is cool Tim. >>> >>> So what image size you deployed at the end? >>> >>> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> I just wanted to thank everyone for their help in getting my pet >>>> project further along, so that now I can announce that PharoLambda is now >>>> working with the V7 minimal image and also supports post mortem debugging >>>> by saving a zipped fuel context onto S3. >>>> >>>> This latter item is particularly satisfying as at a recent serverless >>>> conference (JeffConf) there was a panel where poor development tools on >>>> serverless platforms was highlighted as a real problem. >>>> >>>> In our community weâve had these kinds of tools at our fingertips for >>>> ages - but I donât think the wider development community has really >>>> noticed. Debugging something short lived like a Lambda execution is quite >>>> startling, as the current answer is âadd more loggingâ, and we all know >>>> that sucks. To this end, Iâve created a little screencast showing this in >>>> action - and it was pretty cool because it was a real example I encountered >>>> when I got everything working and was trying my test application out. >>>> >>>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, >>>> so that I can cache many of the artefacts used between different build runs >>>> (this might also be of interest to others using CI systems). >>>> >>>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda >>>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E >>>> >>>> Tim >>>> >>>> >>>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi - Iâve been playing around with getting Pharo to run well on AWS >>>> Lambda. Itâs early days, but I though it might be interesting to share what >>>> Iâve learned so far. >>>> >>>> Usage examples and code at https://gitlab.com/macta/PharoLambda >>>> >>>> With help from many of the folks here, Iâve been able to get a simple >>>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily >>>> try it out yourself. This seems slightly better than what the GoLang folks >>>> have been able to do. >>>> >>>> Tim >>>> >>>> >>>> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

Hi Tim, On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Hey guys, thanks for your enthusiasm around this - and I cannot stress > enough how this was only possible because of the work that has gone into > making Pharo (in particular the 64bit image, as well as having a minimal > image, and some great blog posts on serialising contexts) as well as the > patience from everyone in answering questions and helping me get it all > working. > > Iâm still quite keen to get my execution time back down under 800ms and > Iâd like to actually get back to writing a few skills to automate a few > things around my house. > > To Answer Denisâ question - > > My final footprint is 30.4mb - thats composed of a 22mb image (with a > simple example that pulls in Fuel, ZTimestamp and the S3 Library which > depends on XMLParser) and then the VM (from which I removed obvious dllâs). > > In my original experiments with a 6.0 minimal image - I did manage to get > to a 13.4mb image (which started out as 12mb original size, and then loaded > in STON and had only a simple clock example). I think the sweet spot is > around 20mb total footprint as that seems to get me into the 450ms-900ms > range. > > The 7.0 min image now starts out at 15mb and then Iâm not sure why loading > Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug > into that). > You can do further space analysis using the following expression SpaceTally new printSpaceAnalysis You can do that in an eval and check what's taking space. With measures we can iterate and improve :). > Iâve also found (and this on the back of unserialising the context in my > example) that the way we build images has 15+ saved stack sessions that > have saved on top of each other from the way we build up the images. I > donât yet know the implications of size/speed of these - but we need a > better way of folding executions when we snapshot headless images. Iâm also > not clear if there are any other startup tasks that take precious time > (this also has implications for our fat development images as they take > much longer to appear than they really should). > I'm working on this as I'm writing this mail ;) https://pharo.fogbugz.com/f/cases/20309 https://github.com/pharo-project/pharo/pull/196 I'll write down the implications further in a different thread. > Iâll be exploring some of these size/speed tradeoffâs in follow on > messages. > > But once again, a big thanks - Iâve not enjoyed programming like this for > ages. > > Tim > > On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: > > hi Tim, > > That is..... AWESOME! > > Very nice delivery - it flowed well with great narration. > > I loved @2:17 "this is the interesting piece, because PharoLambda has > serialized the execution context of its application and saved it into [my > S3 bucket] ... [then on the local machine] rematerializes a debugger [on > that context]." > > There is a clarity in your video presentation that really may intrigue > outsiders. As a community we should push this on the usual hacker forums - > ycombinator could be a good starting point (but I'm locked out of my > account there). > An enticing title could be... > "Debugging Lambdas by re-materializing saved execution contexts on your > local machine." > > cheers -ben > > On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> This is cool Tim. >> >> So what image size you deployed at the end? >> >> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >>> I just wanted to thank everyone for their help in getting my pet project >>> further along, so that now I can announce that PharoLambda is now working >>> with the V7 minimal image and also supports post mortem debugging by saving >>> a zipped fuel context onto S3. >>> >>> This latter item is particularly satisfying as at a recent serverless >>> conference (JeffConf) there was a panel where poor development tools on >>> serverless platforms was highlighted as a real problem. >>> >>> In our community weâve had these kinds of tools at our fingertips for >>> ages - but I donât think the wider development community has really >>> noticed. Debugging something short lived like a Lambda execution is quite >>> startling, as the current answer is âadd more loggingâ, and we all know >>> that sucks. To this end, Iâve created a little screencast showing this in >>> action - and it was pretty cool because it was a real example I encountered >>> when I got everything working and was trying my test application out. >>> >>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, >>> so that I can cache many of the artefacts used between different build runs >>> (this might also be of interest to others using CI systems). >>> >>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda >>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E >>> >>> Tim >>> >>> >>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi - Iâve been playing around with getting Pharo to run well on AWS >>> Lambda. Itâs early days, but I though it might be interesting to share what >>> Iâve learned so far. >>> >>> Usage examples and code at https://gitlab.com/macta/PharoLambda >>> >>> With help from many of the folks here, Iâve been able to get a simple >>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily >>> try it out yourself. This seems slightly better than what the GoLang folks >>> have been able to do. >>> >>> Tim >>> >>> >>> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Tim Mackinnon

Hey guys, thanks for your enthusiasm around this - and I cannot stress enough how this was only possible because of the work that has gone into making Pharo (in particular the 64bit image, as well as having a minimal image, and some great blog posts on serialising contexts) as well as the patience from everyone in answering questions and helping me get it all working. Iâm still quite keen to get my execution time back down under 800ms and Iâd like to actually get back to writing a few skills to automate a few things around my house. To Answer Denisâ question - My final footprint is 30.4mb - thats composed of a 22mb image (with a simple example that pulls in Fuel, ZTimestamp and the S3 Library which depends on XMLParser) and then the VM (from which I removed obvious dllâs). In my original experiments with a 6.0 minimal image - I did manage to get to a 13.4mb image (which started out as 12mb original size, and then loaded in STON and had only a simple clock example). I think the sweet spot is around 20mb total footprint as that seems to get me into the 450ms-900ms range. The 7.0 min image now starts out at 15mb and then Iâm not sure why loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug into that). Iâve also found (and this on the back of unserialising the context in my example) that the way we build images has 15+ saved stack sessions that have saved on top of each other from the way we build up the images. I donât yet know the implications of size/speed of these - but we need a better way of folding executions when we snapshot headless images. Iâm also not clear if there are any other startup tasks that take precious time (this also has implications for our fat development images as they take much longer to appear than they really should). Iâll be exploring some of these size/speed tradeoffâs in follow on messages. But once again, a big thanks - Iâve not enjoyed programming like this for ages. Tim > On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: > > hi Tim, > > That is..... AWESOME! > > Very nice delivery - it flowed well with great narration. > > I loved @2:17 "this is the interesting piece, because PharoLambda has serialized the execution context of its application and saved it into [my S3 bucket] ... [then on the local machine] rematerializes a debugger [on that context]." > > There is a clarity in your video presentation that really may intrigue outsiders. As a community we should push this on the usual hacker forums - ycombinator could be a good starting point (but I'm locked out of my account there). > An enticing title could be... > "Debugging Lambdas by re-materializing saved execution contexts on your local machine." > > cheers -ben > > On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > This is cool Tim. > > So what image size you deployed at the end? > > 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > I just wanted to thank everyone for their help in getting my pet project further along, so that now I can announce that PharoLambda is now working with the V7 minimal image and also supports post mortem debugging by saving a zipped fuel context onto S3. > > This latter item is particularly satisfying as at a recent serverless conference (JeffConf) there was a panel where poor development tools on serverless platforms was highlighted as a real problem. > > In our community weâve had these kinds of tools at our fingertips for ages - but I donât think the wider development community has really noticed. Debugging something short lived like a Lambda execution is quite startling, as the current answer is âadd more loggingâ, and we all know that sucks. To this end, Iâve created a little screencast showing this in action - and it was pretty cool because it was a real example I encountered when I got everything working and was trying my test application out. > > Iâve also put a bit of work into tuning the excellent GitLab CI tools, so that I can cache many of the artefacts used between different build runs (this might also be of interest to others using CI systems). > > The Gitlab project is on: https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> > And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E <https://www.youtube.com/watch?v=bNNCT1hLA3E> > > Tim > > >> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> Hi - Iâve been playing around with getting Pharo to run well on AWS Lambda. Itâs early days, but I though it might be interesting to share what Iâve learned so far. >> >> Usage examples and code at https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >> >> With help from many of the folks here, Iâve been able to get a simple example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily try it out yourself. This seems slightly better than what the GoLang folks have been able to do. >> >> Tim > > >

Aug. 14, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Tudor Girba

Hi Tim, The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. Cheers, Doru > On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). > > My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). > > Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. > > > Tim > >> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi tim >> >> I personally do not care much about the syntax but I care about what I >> can do with it >> (ref, cite, ... ) >> I cannot write books in markdown because reference to figures!!!!!! >> were missing. >> >> And of course a parser because markdown is not really nice to parse >> and I will not write a parser because I have something else to do. I >> want to make pillar smaller, simpler, nicer. >> >> Now if someone come up with a parser that parse for REAL a markdown >> that can be extended with decent behavior (figure reference, section >> reference, cite) and can be extended because there are many things >> that can be nice to have (for example I want to be able to write the >> example below) and emit a PillarModel (AST) we can talk to have >> another syntax for Pillar but not before. >> >> [[[test >> 2+3 >>>>> 5 >> ]]] >> >> and being able to verify that the doc is in sync. >> >> >> Stef >> >> >> >> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>> >>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>> >>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>> >>>>> The readme.md that Peter is talking about is gfm markdown >>>> >>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>> (Github uses CommonMarks and adds just couple small extensions.) >>>> >>>> Peter >>>> >>> >>> >> > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Aug. 14, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Tim Mackinnon

Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. Tim > On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi tim > > I personally do not care much about the syntax but I care about what I > can do with it > (ref, cite, ... ) > I cannot write books in markdown because reference to figures!!!!!! > were missing. > > And of course a parser because markdown is not really nice to parse > and I will not write a parser because I have something else to do. I > want to make pillar smaller, simpler, nicer. > > Now if someone come up with a parser that parse for REAL a markdown > that can be extended with decent behavior (figure reference, section > reference, cite) and can be extended because there are many things > that can be nice to have (for example I want to be able to write the > example below) and emit a PillarModel (AST) we can talk to have > another syntax for Pillar but not before. > > [[[test > 2+3 >>>> 5 > ]]] > > and being able to verify that the doc is in sync. > > > Stef > > > > On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >> >> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >> >> Tim >> >> Sent from my iPhone >> >>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>> >>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>> >>>> The readme.md that Peter is talking about is gfm markdown >>> >>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>> (Github uses CommonMarks and adds just couple small extensions.) >>> >>> Peter >>> >> >> >

Aug. 14, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Herby VojÄÃk

Stephane Ducasse wrote: > ah yes. > probably a missing rename during the migration to the new ffi. > > Stef Unfortunately there's more: PharoDatabaseAccessor(DatabaseAccessor)>>handleError:for: [ :ex | self handleError: ex for: command ] in [ | result | self checkPermissionFor: command. result := [ (self useBinding and: [ command useBinding ]) ifTrue: [ command executeBoundIn: self ] ifFalse: [ command executeUnboundIn: self ] ] on: Dialect error do: [ :ex | self handleError: ex for: command ]. aBoolean ifTrue: [ result ] ifFalse: [ result upToEnd ] ] in PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: MessageNotUnderstood(Exception)>>signal ExternalData(Object)>>doesNotUnderstand: #pointerAt: FFIExternalArray class>>fromPointer:type:size: GASqlite3FFI>>blobFrom:at: GASqlite3Statement>>byteArrayAt: GASqlite3Statement>>valueOfColumn: GASqlite3ResultSet>>next GASqlite3ResultSet>>rows GAGlorpDriver>>basicExecuteSQLString: PharoDatabaseAccessor>>basicExecuteSQLString: PharoDatabaseAccessor>>executeCommandUnbound: [..snip..] Now ExternalData does not understand #pointerAt: (only ByteArray and FFIExternalStructureReferenceHandle do, don't know how to fix this quickly... :-( ) Herby > > On Sun, Aug 13, 2017 at 9:04 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> Stephane Ducasse wrote: >>> Do you have the same bug in 5.0? >>> Because I do not know if garage was really tested on 60. >> >> Don't know (don't have it), but last commit in Garage-SQLite >> GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no >> place at all in the image (except supersend in the lone method itself), so >> it definitely looks like it need to rename to ffiBindingOf: for 60. >> >> Herby >> >> >>> Stef >>> >>> On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>> Stephane Ducasse wrote: >>>>> Hi Herby >>>>> >>>>> On which version of Pharo are you trying? Because lot of changes >>>>> happened on Pharo 60 FFI. >>>>> >>>>> Stef >>>>> >>>>> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>>>> Hello! >>>>>> >>>>>> This testing code: >>>>>> >>>>>> | databaseFile login accessor sqlString | >>>>>> databaseFile := Smalltalk imageDirectory asFileReference / >>>>>> 'play.sqlite'. >>>>>> login := Login new >>>>>> database: SQLite3Platform new; >>>>>> host: ''; >>>>>> port: ''; >>>>>> username: ''; >>>>>> password: ''; >>>>>> databaseName: databaseFile fullPath asZnUrl >>>>>> asString; >>>>>> yourself. >>>>>> accessor := DatabaseAccessor forLogin: login. >>>>>> accessor login. >>>>>> sqlString := 'SELECT * FROM AGENT'. >>>>>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>>>>> >>>>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project >>>> >>>> As I wrote here, Pharo 6.1. >>>> >>>> >>>>>> dependency) with: >>>>>> >>>>>> Error: Unable to resolve external type: sqlite3 >>>>>> >>>>>> FFICallout(Object)>>error: >>>>>> FFICallout>>resolveType: >>>>>> FFICallout>>typeName:pointerArity: >>>>>> FFICallout>>argName:indirectIndex:type:ptrArity: >>>>>> FFIFunctionParser>>parseArgument >>>>>> FFIFunctionParser>>parseArguments >>>>>> FFIFunctionParser>>parseNamedFunction: >>>>>> FFICalloutMethodBuilder>>parseSignature: >>>>>> FFICalloutMethodBuilder>>generate >>>>>> FFICalloutMethodBuilder>>build: >>>>>> FFICalloutAPI>>function:module: >>>>>> GASqlite3FFI(Object)>>ffiCall:module: >>>>>> GASqlite3FFI>>apiErrorMessage: >>>>>> GASqlite3FFI>>signal:with:on: >>>>>> GASqlite3FFI>>checkForOk:on: >>>>>> GASqlite3FFI>>prepare:on:with: >>>>>> GASqlite3Statement>>prepare >>>>>> GASqlite3Driver>>prepare: >>>>>> GASqlite3ResultSet>>prepareStatement: >>>>>> GASqlite3ResultSet>>execute:withCollection: >>>>>> GASqlite3ResultSet>>execute:with:on: >>>>>> GASqlite3Driver>>execute:with: >>>>>> GASqlite3Driver>>execute: >>>>>> GAGlorpDriver>>basicExecuteSQLString: >>>>>> PharoDatabaseAccessor>>basicExecuteSQLString: >>>>>> UndefinedObject>>DoIt >>>>>> OpalCompiler>>evaluate >>>>>> [..snip..] >>>>>> >>>>>> Problem seems to be that in FFICallout>> resolveType:, the line >>>>>> >>>>>> binding := resolver ffiBindingOf: name asSymbol. >>>>>> >>>>>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>>>>> the >>>>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>>>>> >>>>>> nbBindingOf: aTypeName >>>>>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: >>>>>> aTypeName >>>>>> ] >>>>>> >>>>>> though. If I copy near-mindlessly and add: >>>>>> >>>>>> ffiBindingOf: aTypeName >>>>>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>>>>> aTypeName ] >>>>>> >>>>>> then the code above fails correctly with: 'no such table: AGENT'. >>>>>> >>>>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>>>>> driver? >>>>>> >>>>>> Herby >>>> >> >

Aug. 13, 2017

Re: [Pharo-users] Probably a bug in Garage SQLite

by Stephane Ducasse

ah yes. probably a missing rename during the migration to the new ffi. Stef On Sun, Aug 13, 2017 at 9:04 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: >> >> Do you have the same bug in 5.0? >> Because I do not know if garage was really tested on 60. > > > Don't know (don't have it), but last commit in Garage-SQLite > GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no > place at all in the image (except supersend in the lone method itself), so > it definitely looks like it need to rename to ffiBindingOf: for 60. > > Herby > > >> >> Stef >> >> On Sun, Aug 13, 2017 at 8:41 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>> >>> Stephane Ducasse wrote: >>>> >>>> Hi Herby >>>> >>>> On which version of Pharo are you trying? Because lot of changes >>>> happened on Pharo 60 FFI. >>>> >>>> Stef >>>> >>>> On Sun, Aug 13, 2017 at 6:11 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>>>> >>>>> Hello! >>>>> >>>>> This testing code: >>>>> >>>>> | databaseFile login accessor sqlString | >>>>> databaseFile := Smalltalk imageDirectory asFileReference / >>>>> 'play.sqlite'. >>>>> login := Login new >>>>> database: SQLite3Platform new; >>>>> host: ''; >>>>> port: ''; >>>>> username: ''; >>>>> password: ''; >>>>> databaseName: databaseFile fullPath asZnUrl >>>>> asString; >>>>> yourself. >>>>> accessor := DatabaseAccessor forLogin: login. >>>>> accessor login. >>>>> sqlString := 'SELECT * FROM AGENT'. >>>>> (accessor basicExecuteSQLString: sqlString) contents inspect. >>>>> >>>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project >>> >>> >>> As I wrote here, Pharo 6.1. >>> >>> >>>>> dependency) with: >>>>> >>>>> Error: Unable to resolve external type: sqlite3 >>>>> >>>>> FFICallout(Object)>>error: >>>>> FFICallout>>resolveType: >>>>> FFICallout>>typeName:pointerArity: >>>>> FFICallout>>argName:indirectIndex:type:ptrArity: >>>>> FFIFunctionParser>>parseArgument >>>>> FFIFunctionParser>>parseArguments >>>>> FFIFunctionParser>>parseNamedFunction: >>>>> FFICalloutMethodBuilder>>parseSignature: >>>>> FFICalloutMethodBuilder>>generate >>>>> FFICalloutMethodBuilder>>build: >>>>> FFICalloutAPI>>function:module: >>>>> GASqlite3FFI(Object)>>ffiCall:module: >>>>> GASqlite3FFI>>apiErrorMessage: >>>>> GASqlite3FFI>>signal:with:on: >>>>> GASqlite3FFI>>checkForOk:on: >>>>> GASqlite3FFI>>prepare:on:with: >>>>> GASqlite3Statement>>prepare >>>>> GASqlite3Driver>>prepare: >>>>> GASqlite3ResultSet>>prepareStatement: >>>>> GASqlite3ResultSet>>execute:withCollection: >>>>> GASqlite3ResultSet>>execute:with:on: >>>>> GASqlite3Driver>>execute:with: >>>>> GASqlite3Driver>>execute: >>>>> GAGlorpDriver>>basicExecuteSQLString: >>>>> PharoDatabaseAccessor>>basicExecuteSQLString: >>>>> UndefinedObject>>DoIt >>>>> OpalCompiler>>evaluate >>>>> [..snip..] >>>>> >>>>> Problem seems to be that in FFICallout>> resolveType:, the line >>>>> >>>>> binding := resolver ffiBindingOf: name asSymbol. >>>>> >>>>> actually produces nil, resolver being GASqlite3FFI class. If looking at >>>>> the >>>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is >>>>> >>>>> nbBindingOf: aTypeName >>>>> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: >>>>> aTypeName >>>>> ] >>>>> >>>>> though. If I copy near-mindlessly and add: >>>>> >>>>> ffiBindingOf: aTypeName >>>>> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: >>>>> aTypeName ] >>>>> >>>>> then the code above fails correctly with: 'no such table: AGENT'. >>>>> >>>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite >>>>> driver? >>>>> >>>>> Herby >>> >>> >> > >

Aug. 13, 2017