- Pharo-users - lists.pharo.org

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

by H. Hirzel

Offray, thanks for the nice write-up about the general usefulness of Markdown for writing papers. Stephen D. wrote yesterday in a terse way "We can change the syntax or propose an alternate one as soon as it uses the same internal structure. Stef" This means that Pillars tagging system may be changed to a more generally known tagging system later. I assume with 'internal structure' he refers to the AST/Document Object Model of Pillar which would need to be aligned with one of another markup system. Maybe the gap is not all that large. Personally I think as well that if Pharo could also be used as a markdown (commonmark) editor with its tool-chain to generate different types of documents would expand the area of application considerably. --Hannes On 8/15/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > While I appreciate the historical perspective, I continue to be with Tim > on this (and I consider myself part of the Pharo Community). I have also > personal preferences for other light markup languages (like txt2tags[1] > and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is > support everything Stephan or any professional author wants to do and in > fact you can create full books with it, including references, tables, > images, and bibliographic references (which are not supported by Pillar > AFAIK), but also because is an emerging standard beyond the programmers > community, including academicians and researchers with the Scholarly > Markdown[3] initiative and with possibilities to import and export > from/to several markup languages[4]. > > [1] http://txt2tags.org/ > [2] https://www.dokuwiki.org/wiki:syntax > [3] http://scholmd.org/ > [4] http://pandoc.org/ > > I don't share the vision of particular communities choosing particular > markup languages as default, because, if you already payed the price of > learning that particular language/environment, you are willing to pay > the price with whatever that community choose in other fronts like DVCS > or markup languages. Python community supports reST, but also markdown > and several other markup languages and Jupyter notebooks[5] user > Markdown by default. In fact, the Iceberg Git support shows the > increasing concern to bridge the Pharo world with the stuff you already > know and I think that a similar approach should be taken in the > documentation/markup front, even if this implies breaking compatibility > with the canonical Smalltalk way (TM) (I really like that critical > approach from Pharo to the past). > > [5] http://jupyter.org/ > > That being said, I don't think that should be exclusively one way or > another. We can have Pillar and (Pandoc's) Markdown, if the community > doesn't reach and agreement on only one. > > I plan to explore the Brick editor once I have time and will try to add > Pandoc's Markdown support. Unfortunately, in the past I have not had > many luck testing and giving feedback on Moose alpha releases of tools > and my questions/comments on them remain largely unanswered or simply > ignored for long time (or just forever), so my priority on testing these > tools have just decreased, but once Brick editor become more well > supported, Pandoc's Markdown support for it will be in my target and > concerns. > > Cheers, > > Offray > > On 14/08/17 12:48, Jimmie Houchin wrote: >> >> Thank Tim, >> >> My primary reason to submit the message was not to necessarily >> persuade you per se. But to provide something historical for the >> mailing list as this can be a recurring subject. Why use Pillar markup >> instead of ???(insert personal favorite). >> >> If Pharo were to decide on a different markup language. The question >> would still be which one, why and then how do we proceed. Then our >> extensions may not be accepted by the greater body of users of said >> markup. We would still be contributing to the fragmentation of markup. >> As far as familiarity, I don't know. And familiarity with what. I do >> not find that reStructuredText to be similar to Markdown. >> >> It would stop people from asking why we aren't using Markdown. But it >> wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown >> or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or >> insert latest greatest creation markup or current flavor of the >> moment. Which is why I wanted to point out that there is no consensus >> among users of markup languages. At least I do not see one. Nor do I >> believe that we have seen the end of creation of new markup languages. >> >> I understand the difficulty, though I do not suffer from it as I have >> not mastered any of those other languages. I have been using >> Squeak/Pharo for a long time. I struggle when I look at those other >> languages. To me they are the foreign ones. >> >> And I do not see these emerging standards you refer to. When we see >> Python, Ruby, Perl, C++, various projects, etc. communities having >> consensus on a common markup for documentation. Then I see an emerging >> standard. Until then it seems to possibly be an emerging standard for >> a particular markup language which is among the set of markup languages. >> >> If we were the only language and development environment doing our own >> thing. Then we might have a very good reason to talk. But we are not. >> Python with its enormous community does its own thing. I don't know >> that other languages have a consensus for markup for documentation >> except for Python and Pharo. >> >> While writing this email I went and discovered that even GitHub is not >> dogmatic about the subject. Obviously they have an opinion. But they >> permit multiple markup languages. Quite possibly someone could write a >> Pillar tool for GitHub to use and then we could just submit >> Readme.pillar for our projects. :) >> >> https://github.com/github/markup >> >> Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; >> .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; >> .pod. So it seems that there are many communities on GitHub who >> prefer their own markup and tools. >> >> We could possibly write the Pillar tool for GitHub or an exporter to >> the preferred markup language of the above. >> >> This author provides arguments for using reStructuredText over >> Markdown for GitHub documents. Citing deficiencies in Markdown and >> expressiveness in reST. >> >> https://gist.github.com/dupuy/1855764 >> >> So again. I am just not seeing a consensus around any emerging >> standard for "the markup language". >> >> At the same time if you are desirous of writing in Commonmark in your >> text editor. Can you not write conversion software that goes from >> Commonmark to Pillar? Thus, meeting want you want and what we require? >> If you were to do so, you would definitely have a good understanding >> of the differences in philosophy and capabilities of each. Just a >> thought. >> >> Any way, thanks for engaging in the conversation. I wasn't targeting >> you personally, but rather the topic. You are not alone in your >> thinking. The Pharo community is not alone in its thinking either. >> >> Thanks. >> >> Jimmie >> >> >> >> >> On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >>> Jimmie et al. nicely reasoned arguments - and Doru's point about >>> controlling the syntax is an interesting one that I hadnât thought >>> about. >>> >>> Personally, I find having too many similar syntaxâs confusing - >>> contributing to things is hard enough - having to remember that its >>> !! Instead of ## and ââ instead of ** is just frustrating for me. >>> >>> My vote would be what Peter suggested - use >>> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >>> on top for things that Stef was mentioning. (I think thatâs what Iâve >>> understood gfm markdown is). >>> >>> Sure, maybe we were first with Pillar, but for me, lots of >>> programming is in other languages, and I use Smalltalk where I can, >>> and a hybrid of multiple languages and projects is often the reality >>> - so a lowest common denominator of Markdown is just easier. The fact >>> that we are quite close to what our colleagues in other languages use >>> (regardless of what Python has chosen), is quite interesting. >>> >>> That said, if the community wants to stick to its gunâs thats fine - >>> I will probably still investigate how to use Commonmark for myself, >>> and will still contribute to Pillar docs where I can (and curse >>> history) - but I think we are long better off trying to join emerging >>> standards where we can particularly if they arenât our core language >>> thing. And it just makes it less frictionless for ourselves and >>> newcomers. >>> >>> Of course, if we were to move, we would need to translate a lot of >>> quality docs to a new format - but I would be up for contributing to >>> that if that was a deciding factor. >>> >>> Tim >>> >>> >>>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>>> <mailto:jlhouchin@gmail.com>> wrote: >>>> >>>> TL;DR >>>> >>>> Main points: >>>> Their is no universally accepted markup language. >>>> Other communities use their own markup and tools and their markup >>>> and tools choice is not determine by other communities decisions. >>>> We need a language and tool chain that we can control and maintain >>>> which accomplishes our goals. >>>> Our language and tools already exist and have existed for longer >>>> than most of the other markup languages. Of course they existed in >>>> various different forms over the years and have evolved into what >>>> they currently are. >>>> It might be nice to have a GFM Markdown exporter from Pillar for >>>> GitHub projects. >>>> >>>> >>>> I just want to comment on the fact that there is no universal markup >>>> language that every development community has settled upon. Making >>>> Markdown or some variant the markup language for Pharo only aligns >>>> us with a certain part of the development community. Even Markdown >>>> is not unified as is evident by the discussion. >>>> >>>> It is true that GitHub uses their variant of Markdown. And as long >>>> as we use GitHub we will need to use their variant for documents >>>> that reside on their system. >>>> >>>> However as a significant counter example to lets all use gfm >>>> Markdown, is the Python community and their documentation. >>>> >>>> https://docs.python.org/devguide/documenting.html >>>> """ >>>> 7. Documenting Python >>>> The Python language has a substantial body of documentation, much of >>>> it contributed by various authors. The markup used for the Python >>>> documentation is reStructuredText, developed by the docutils >>>> project, amended by custom directives and using a toolset named >>>> Sphinx to post-process the HTML output. >>>> >>>> This document describes the style guide for our documentation as >>>> well as the custom reStructuredText markup introduced by Sphinx to >>>> support Python documentation and how it should be used. >>>> >>>> The documentation in HTML, PDF or EPUB format is generated from text >>>> files written using the reStructuredText format and contained in the >>>> CPython Git repository. >>>> """ >>>> >>>> So the Python community uses their own markup language and their own >>>> tool chain. So therefore, it is not wrong for a community to go >>>> their own way, for their own reasons. Even within the conventional >>>> file based languages such as Python. >>>> >>>> The fact that you have tools such as Pandoc, suggest that there is >>>> not true uniformity or unanimity among developers as to the best >>>> markup language or tool chain. >>>> >>>> I believe that a language that we can control and maintain is better >>>> than adopting some other foreign markup language that is neither >>>> better, nor unanimously used by all. That would ultimately >>>> potentially require extensions to accomplish our goals. Then we >>>> would be maintaining someone else's language with our extensions >>>> that may or may not be accepted by the larger community. This does >>>> not prevent but rather encourages fragmentation of the existing >>>> Markdown. >>>> >>>> Regardless, Pillar markup already exists. The tools in Pharo already >>>> understand it. Should someone desire to use Pharo which is far more >>>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>>> Then it should be worth their effort to learn our tools. >>>> >>>> Pillar markup is older than Markdown, etc. It's history begins in >>>> SmallWiki. It isn't as if we jumped up and decided to create >>>> something new in order to be different. Our markup and tools are >>>> older. They (and others) are the ones that decided to do their own >>>> markup and tools. And it is okay that they did so. Nothing wrong >>>> with doing so. Every community has the right to what they believe is >>>> best for their community. Even if other communities disagree. >>>> >>>> The ability to control and maintain is highly valuable. We can >>>> understand what our requirements are for today. But we can not know >>>> what the requirements are in the future. Nor can we know that >>>> Markdown or whomever will have such requirements when they appear. >>>> It is easy to see in the beginning with the Squeak Wiki syntax to >>>> the now Pillar syntax, changes that have been made to accommodate >>>> new requirements as they became known. We need to maintain that >>>> ability. Sure we would reserve the right to do so in any language we >>>> adopt. But the then current standard bearer of said language would >>>> determine whether what we do is acceptable and incorporate or >>>> whether we are then in fact adding to their fragmentation. Pillar is >>>> ours. There is not fragmentation when we evolve. >>>> >>>> However, since we have made a decision to use GitHub and GitHub has >>>> made a decision to use their own GFM Markdown. It might be nice to >>>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>>> way we can use our own tools and markup language to accomplish >>>> whatever we want to accomplish. Including generating a Readme.md for >>>> our GitHub projects. >>>> >>>> Just wanted to toss out this simple opinion and facts about the >>>> situation. >>>> >>>> Jimmie >>>> >>>> >>>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>>> 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. 15, 2017

Re: [Pharo-users] [ANN] VistaCursor now scalable

by webwarrior

Torsten Bergmann wrote > Hi, > > Mike Davis asked about changing the cursor size as he runs Pharo with > Windows 10 on a Microsoft Surface > @ 2736 x 1824 dpi. He discussed on Discord and said that all of the > display is well scaled, except the mouse > cursor which is too small for him. > > As the Windows VM supports larger cursors I added some support to my > loadable goodie package "VistaCursor" now. > So there is now a new setting to scale the provided cursors (see > screenshots). Either freshly load the package > from catalog or update to "VistaCursors-TorstenBergmann.5" if you want to > check this out. > > This might be also be useful for presentations. > > Have fun > T. > > > vistacursor.png (37K) > <http://forum.world.st/attachment/4961238/0/vistacursor.png> This only partly fixes the problem. Not all cursors are replaced - e.g. cursor for text selection is sitll tiny. Also seting has to be changed every time someone switches to another computer or even to another display with different DPI. I opened an issue in bugtracker (https://pharo.fogbugz.com/f/cases/20281/Small-cursor-on-high-DPI-displays-i…) some time ago, but nobody has reacted yet. -- View this message in context: http://forum.world.st/ANN-VistaCursor-now-scalable-tp4961238p4961322.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 15, 2017

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

by Guillermo Polito

On Mon, Aug 14, 2017 at 4:42 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guille - just running SpaceTally on my dev image to get a feel for it. > It turns out that in the minimal images youâve been creating, its not > loaded (makes sense). > Yup, it's loaded afterwards. All packages are loaded through metacello baselines. We should start refactoring and making standalone projects, each one with a baseline for himself, and his own dependencies described. I was checking on your gitlab and I have probably no access: how are you finally loading packages in the bootstrap image? Can you share that with us in text? I'd like to improve that situation. > Iâm wondering if there is an easy way to import it in (I guess that > package should be in the Pharo git tree I cloned to get Fuel loaded right? > Or is there a separate standalone source?). > Yes it is, you can get the package programatically doing SpaceTally package name And furthermore, get the baseline that currently is loading by doing package := SpaceTally package name. BaselineOf subclasses select: [ :e | e project version packages anySatisfy: [ :p | p name = package ]]. > > Thanks for all the support, and your email about why the contexts stack up > is very well received (I will comment over there). > > By the way - it looks like Martin Fowler picked up on this announcement - > so maybe we might get some interest from his mass of followers. > > Tim > > On 14 Aug 2017, at 10:49, 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. 15, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, While I appreciate the historical perspective, I continue to be with Tim on this (and I consider myself part of the Pharo Community). I have also personal preferences for other light markup languages (like txt2tags[1] and dokuwiki's[2]), but I will stick with Pandoc's Markdown, because is support everything Stephan or any professional author wants to do and in fact you can create full books with it, including references, tables, images, and bibliographic references (which are not supported by Pillar AFAIK), but also because is an emerging standard beyond the programmers community, including academicians and researchers with the Scholarly Markdown[3] initiative and with possibilities to import and export from/to several markup languages[4]. [1] http://txt2tags.org/ [2] https://www.dokuwiki.org/wiki:syntax [3] http://scholmd.org/ [4] http://pandoc.org/ I don't share the vision of particular communities choosing particular markup languages as default, because, if you already payed the price of learning that particular language/environment, you are willing to pay the price with whatever that community choose in other fronts like DVCS or markup languages. Python community supports reST, but also markdown and several other markup languages and Jupyter notebooks[5] user Markdown by default. In fact, the Iceberg Git support shows the increasing concern to bridge the Pharo world with the stuff you already know and I think that a similar approach should be taken in the documentation/markup front, even if this implies breaking compatibility with the canonical Smalltalk way (TM) (I really like that critical approach from Pharo to the past). [5] http://jupyter.org/ That being said, I don't think that should be exclusively one way or another. We can have Pillar and (Pandoc's) Markdown, if the community doesn't reach and agreement on only one. I plan to explore the Brick editor once I have time and will try to add Pandoc's Markdown support. Unfortunately, in the past I have not had many luck testing and giving feedback on Moose alpha releases of tools and my questions/comments on them remain largely unanswered or simply ignored for long time (or just forever), so my priority on testing these tools have just decreased, but once Brick editor become more well supported, Pandoc's Markdown support for it will be in my target and concerns. Cheers, Offray On 14/08/17 12:48, Jimmie Houchin wrote: > > Thank Tim, > > My primary reason to submit the message was not to necessarily > persuade you per se. But to provide something historical for the > mailing list as this can be a recurring subject. Why use Pillar markup > instead of ???(insert personal favorite). > > If Pharo were to decide on a different markup language. The question > would still be which one, why and then how do we proceed. Then our > extensions may not be accepted by the greater body of users of said > markup. We would still be contributing to the fragmentation of markup. > As far as familiarity, I don't know. And familiarity with what. I do > not find that reStructuredText to be similar to Markdown. > > It would stop people from asking why we aren't using Markdown. But it > wouldn't prevent others. Why aren't we using GFM Markdown, or Kramdown > or Commonmark or ...? Why aren't we using YAML or reST or AsciiDoc or > insert latest greatest creation markup or current flavor of the > moment. Which is why I wanted to point out that there is no consensus > among users of markup languages. At least I do not see one. Nor do I > believe that we have seen the end of creation of new markup languages. > > I understand the difficulty, though I do not suffer from it as I have > not mastered any of those other languages. I have been using > Squeak/Pharo for a long time. I struggle when I look at those other > languages. To me they are the foreign ones. > > And I do not see these emerging standards you refer to. When we see > Python, Ruby, Perl, C++, various projects, etc. communities having > consensus on a common markup for documentation. Then I see an emerging > standard. Until then it seems to possibly be an emerging standard for > a particular markup language which is among the set of markup languages. > > If we were the only language and development environment doing our own > thing. Then we might have a very good reason to talk. But we are not. > Python with its enormous community does its own thing. I don't know > that other languages have a consensus for markup for documentation > except for Python and Pharo. > > While writing this email I went and discovered that even GitHub is not > dogmatic about the subject. Obviously they have an opinion. But they > permit multiple markup languages. Quite possibly someone could write a > Pillar tool for GitHub to use and then we could just submit > Readme.pillar for our projects. :) > > https://github.com/github/markup > > Shows that GitHub allows for .markdown, .mdown, .mkdn, .md; .textile; > .rdoc; .org; .creole; .mediawiki, .wiki; .rst; .asciidoc, .adoc, .asc; > .pod. So it seems that there are many communities on GitHub who > prefer their own markup and tools. > > We could possibly write the Pillar tool for GitHub or an exporter to > the preferred markup language of the above. > > This author provides arguments for using reStructuredText over > Markdown for GitHub documents. Citing deficiencies in Markdown and > expressiveness in reST. > > https://gist.github.com/dupuy/1855764 > > So again. I am just not seeing a consensus around any emerging > standard for "the markup language". > > At the same time if you are desirous of writing in Commonmark in your > text editor. Can you not write conversion software that goes from > Commonmark to Pillar? Thus, meeting want you want and what we require? > If you were to do so, you would definitely have a good understanding > of the differences in philosophy and capabilities of each. Just a thought. > > Any way, thanks for engaging in the conversation. I wasn't targeting > you personally, but rather the topic. You are not alone in your > thinking. The Pharo community is not alone in its thinking either. > > Thanks. > > Jimmie > > > > > On 08/14/2017 11:34 AM, Tim Mackinnon wrote: >> Jimmie et al. nicely reasoned arguments - and Doru's point about >> controlling the syntax is an interesting one that I hadnât thought >> about. >> >> Personally, I find having too many similar syntaxâs confusing - >> contributing to things is hard enough - having to remember that its >> !! Instead of ## and ââ instead of ** is just frustrating for me. >> >> My vote would be what Peter suggested - use >> http://spec.commonmark.org/0.28/ and put our Pillar extensions back >> on top for things that Stef was mentioning. (I think thatâs what Iâve >> understood gfm markdown is). >> >> Sure, maybe we were first with Pillar, but for me, lots of >> programming is in other languages, and I use Smalltalk where I can, >> and a hybrid of multiple languages and projects is often the reality >> - so a lowest common denominator of Markdown is just easier. The fact >> that we are quite close to what our colleagues in other languages use >> (regardless of what Python has chosen), is quite interesting. >> >> That said, if the community wants to stick to its gunâs thats fine - >> I will probably still investigate how to use Commonmark for myself, >> and will still contribute to Pillar docs where I can (and curse >> history) - but I think we are long better off trying to join emerging >> standards where we can particularly if they arenât our core language >> thing. And it just makes it less frictionless for ourselves and >> newcomers. >> >> Of course, if we were to move, we would need to translate a lot of >> quality docs to a new format - but I would be up for contributing to >> that if that was a deciding factor. >> >> Tim >> >> >>> On 14 Aug 2017, at 16:41, Jimmie Houchin <jlhouchin(a)gmail.com >>> <mailto:jlhouchin@gmail.com>> wrote: >>> >>> TL;DR >>> >>> Main points: >>> Their is no universally accepted markup language. >>> Other communities use their own markup and tools and their markup >>> and tools choice is not determine by other communities decisions. >>> We need a language and tool chain that we can control and maintain >>> which accomplishes our goals. >>> Our language and tools already exist and have existed for longer >>> than most of the other markup languages. Of course they existed in >>> various different forms over the years and have evolved into what >>> they currently are. >>> It might be nice to have a GFM Markdown exporter from Pillar for >>> GitHub projects. >>> >>> >>> I just want to comment on the fact that there is no universal markup >>> language that every development community has settled upon. Making >>> Markdown or some variant the markup language for Pharo only aligns >>> us with a certain part of the development community. Even Markdown >>> is not unified as is evident by the discussion. >>> >>> It is true that GitHub uses their variant of Markdown. And as long >>> as we use GitHub we will need to use their variant for documents >>> that reside on their system. >>> >>> However as a significant counter example to lets all use gfm >>> Markdown, is the Python community and their documentation. >>> >>> https://docs.python.org/devguide/documenting.html >>> """ >>> 7. Documenting Python >>> The Python language has a substantial body of documentation, much of >>> it contributed by various authors. The markup used for the Python >>> documentation is reStructuredText, developed by the docutils >>> project, amended by custom directives and using a toolset named >>> Sphinx to post-process the HTML output. >>> >>> This document describes the style guide for our documentation as >>> well as the custom reStructuredText markup introduced by Sphinx to >>> support Python documentation and how it should be used. >>> >>> The documentation in HTML, PDF or EPUB format is generated from text >>> files written using the reStructuredText format and contained in the >>> CPython Git repository. >>> """ >>> >>> So the Python community uses their own markup language and their own >>> tool chain. So therefore, it is not wrong for a community to go >>> their own way, for their own reasons. Even within the conventional >>> file based languages such as Python. >>> >>> The fact that you have tools such as Pandoc, suggest that there is >>> not true uniformity or unanimity among developers as to the best >>> markup language or tool chain. >>> >>> I believe that a language that we can control and maintain is better >>> than adopting some other foreign markup language that is neither >>> better, nor unanimously used by all. That would ultimately >>> potentially require extensions to accomplish our goals. Then we >>> would be maintaining someone else's language with our extensions >>> that may or may not be accepted by the larger community. This does >>> not prevent but rather encourages fragmentation of the existing >>> Markdown. >>> >>> Regardless, Pillar markup already exists. The tools in Pharo already >>> understand it. Should someone desire to use Pharo which is far more >>> different from Python/Ruby/etc. than Pillar syntax is from Markdown. >>> Then it should be worth their effort to learn our tools. >>> >>> Pillar markup is older than Markdown, etc. It's history begins in >>> SmallWiki. It isn't as if we jumped up and decided to create >>> something new in order to be different. Our markup and tools are >>> older. They (and others) are the ones that decided to do their own >>> markup and tools. And it is okay that they did so. Nothing wrong >>> with doing so. Every community has the right to what they believe is >>> best for their community. Even if other communities disagree. >>> >>> The ability to control and maintain is highly valuable. We can >>> understand what our requirements are for today. But we can not know >>> what the requirements are in the future. Nor can we know that >>> Markdown or whomever will have such requirements when they appear. >>> It is easy to see in the beginning with the Squeak Wiki syntax to >>> the now Pillar syntax, changes that have been made to accommodate >>> new requirements as they became known. We need to maintain that >>> ability. Sure we would reserve the right to do so in any language we >>> adopt. But the then current standard bearer of said language would >>> determine whether what we do is acceptable and incorporate or >>> whether we are then in fact adding to their fragmentation. Pillar is >>> ours. There is not fragmentation when we evolve. >>> >>> However, since we have made a decision to use GitHub and GitHub has >>> made a decision to use their own GFM Markdown. It might be nice to >>> have a GFM Markdown exporter from Pillar for GitHub projects. This >>> way we can use our own tools and markup language to accomplish >>> whatever we want to accomplish. Including generating a Readme.md for >>> our GitHub projects. >>> >>> Just wanted to toss out this simple opinion and facts about the >>> situation. >>> >>> Jimmie >>> >>> >>> On 08/14/2017 04:10 AM, Tudor Girba wrote: >>>> 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. 15, 2017

[ANN] VistaCursor now scalable

by Torsten Bergmann

Hi, Mike Davis asked about changing the cursor size as he runs Pharo with Windows 10 on a Microsoft Surface @ 2736 x 1824 dpi. He discussed on Discord and said that all of the display is well scaled, except the mouse cursor which is too small for him. As the Windows VM supports larger cursors I added some support to my loadable goodie package "VistaCursor" now. So there is now a new setting to scale the provided cursors (see screenshots). Either freshly load the package from catalog or update to "VistaCursors-TorstenBergmann.5" if you want to check this out. This might be also be useful for presentations. Have fun T.

Aug. 14, 2017

[Github Repo] I just pushed template to quickly start Pharo / Teapot

by Torsten Bergmann

Hi sergio, why not use my existing "Tealight" project which is (similar to Teapot) also available from Pharo catalog. It is still lightweight as it is just a few extensions to Teapot. You will find it here: https://github.com/astares/Tealight the page includes the full documentation and after reading it you should be able to see: - that you can even start the server quickly from the world menu after loading - how easy it is to tinker and experiment with dynamic routes and Teapot in an interactive way - how easy it is to provide a REST interface by having methods annotated with REST specific pragmas - to even provide a versioned REST interface (also defined using pragmas) The document should easily explain all this, esepcially read "Defining a REST based interface". This project is around since last october now (see http://forum.world.st/ANN-Tealight-td4918431.html) Lately I even added the possibility to remove one or all the dynamic routes in a teapot inspector (see attached screenshot). That makes it even easier to experiment lively with a teapot instance and different URLs one wants to catch. Have fun Torsten

Aug. 14, 2017

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

by Tudor Girba

Hi, > On Aug 14, 2017, at 3:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > again, I think this is a discussion for pharo-dev. > Please keep it there (is good discussion, btw ;) ). > > What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) I am for it, but there will be some work to repackage PetitParser2. Also, I notice that the French lessons start to pay off :) Cheers, Doru > Esteban > > >> On 14 Aug 2017, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> 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." >> >> > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

Aug. 14, 2017

[Github Repo] I just pushed template to quickly start Pharo / Teapot

by sergio ruiz

Hi, All.. Just wanted to let everyone know that I just put together a quick little project using Pharo and Teapot to build a template for a REST server. I have been experimenting with this a lot lately, so i build this so I could quickly start up and play with a new idea. Have a look over at: https://github.com/sergio101/rest_template ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Aug. 14, 2017

Re: [Pharo-users] Big Glorp problem w/ type coercion, pls help

by Herby VojÄÃk

FYI, used a workaround: TowergameDao >> findStateByAgent: anAgent | workaround | workaround := anAgent ifNotNil: [ ByteArray withAll: anAgent id ]. ^ self glorpSession readOneOf: TgState where: [ :one | one agent id = workaround ] But it is _ugly_ (though, it actually generates the same short SQL; it was RelationExpression >> condensePrimaryKeyComparison which inspired me to do this). I am sure one of the points of Glorp is to be able to write the original: findStateByAgent: anAgent ^ self glorpSession readOneOf: TgState where: [ :one | one agent = anAgent ] Is it true (should this work)? Herby Herby VojÄÃk wrote: > Esteban A. Maringolo wrote: >> Do you have the code somewhere loadable? Reading chunk is something I >> do only when everything crashed :D >> Esteban A. Maringolo > > I will attach the .st files... not loadable as its in private on-premise > git repo :-( > > Thank you very much, > > Herby > >> 2017-08-14 13:44 GMT-03:00 Herby VojÄÃk<herby(a)mailbox.sk>: >>> Hello! >>> >>> I encountered a problem with OneToOneMapping and type coercion. When >>> writing >>> data, thing work; when reading data, the right child of relation >>> fails to >>> convert. >>> >>> I tried everything possible to inject converters (even subclassing >>> GlorpBlobType), but to no avail. RelationExpression passes conversion >>> to its >>> left child: >>> >>> convertedDbValueOf: anObject >>> "Assume that our types match, so we can ask either child to do the >>> conversion. That isn't guaranteed, but should at least work for the >>> common >>> cases." >>> ^leftChild convertedDbValueOf: anObject. >>> >>> but the left child is FieldExpression in case of OneToOneMapping, which: >>> >>> convertedDbValueOf: anObject >>> "We don't do any conversion" >>> ^anObject >>> >>> What is strange, writing works (even the OneToOneMapping, I opened the >>> sqlite file with an explorer), but second SELECT, one using the relation >>> (`state := self dao findStateByAgent: agent` in clientSync), fails with >>> "GlorpDatabaseReadError: Could not coerce arguments". FWIW, the first >>> one >>> _does_ convert when creating bindings, as it uses MappingExpression >>> as left >>> child (stepped over it in debugger). >>> >>> >>> >>> Is it meant to be a strange case that primary key is something >>> non-primitive >>> needing coercion (in this case, it is a UUID which needs coercion to >>> ByteArray, even if it is its subclass)? >>> >>> >>> >>> Here's the stack of running the test which fails: >>> >>> 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: >>> Error(Exception)>>signal >>> Error(Exception)>>signal: >>> ExternalLibraryFunction(Object)>>error: >>> ExternalLibraryFunction(Object)>>externalCallFailed >>> ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: >>> UDBCSQLite3Library>>apiBindBlob:atColumn:with:with:with: >>> UDBCSQLite3Library>>with:at:putBlob: >>> UDBCSQLite3Statement>>at:putByteArray: >>> UDBCSQLite3ResultSet>>execute:withIndex:withValue: >>> [ :v | i := self execute: statement withIndex: i withValue: v ] in >>> UDBCSQLite3ResultSet>>execute:withCollection: >>> OrderedCollection>>do: >>> UDBCSQLite3ResultSet>>execute:withCollection: >>> UDBCSQLite3ResultSet>>execute:with:on: >>> UDBCSQLite3Connection>>execute:with: >>> GlorpSQLite3Driver>>basicExecuteSQLString:binding: >>> PharoDatabaseAccessor>>executeCommandBound: >>> QuerySelectCommand(DatabaseCommand)>>executeBoundIn: >>> [ (self useBinding and: [ command useBinding ]) >>> ifTrue: [ command executeBoundIn: self ] >>> ifFalse: [ command executeUnboundIn: self ] ] 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>>on:do: >>> [ | 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: >>> [ caught := true. >>> self wait. >>> blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: >>> BlockClosure>>ensure: >>> Semaphore>>critical: >>> PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor: >>> [ session accessor executeCommand: command returnCursor: true ] in >>> SimpleQuery>>rowsFromDatabaseWithParameters: >>> BlockClosure>>on:do: >>> SimpleQuery>>rowsFromDatabaseWithParameters: >>> SimpleQuery(AbstractReadQuery)>>readFromDatabaseWithParameters: >>> SimpleQuery(AbstractReadQuery)>>executeWithParameters:in: >>> GlorpSession>>execute: >>> GlorpSession>>readOneOf:where: >>> TowergameDao>>findStateByAgent: >>> [ | agent state | >>> agent := self dao findAgentById: anObject agentId. >>> state := self dao findStateByAgent: agent. >>> ^ NeoJSONObject new >>> agentId: agent id; >>> stateVersion: state version; >>> totalAnsweredQuestions: >>> (NeoJSONObject new >>> good: 0; >>> bad: 0; >>> yourself); >>> yourself ] in Towergame>>clientSync: >>> [ myUnitOfWork := self hasUnitOfWork not. >>> myUnitOfWork >>> ifTrue: [ self beginUnitOfWork ]. >>> result := aBlock numArgs = 1 >>> ifTrue: [ aBlock value: self ] >>> ifFalse: [ aBlock value ]. >>> myUnitOfWork >>> ifTrue: [ self commitUnitOfWork ] ] in GlorpSession>>inUnitOfWorkDo: >>> BlockClosure>>ifCurtailed: >>> GlorpSession>>inUnitOfWorkDo: >>> TowergameDao>>inUnitOfWorkDo: >>> Towergame>>clientSync: >>> TowergameSyncTests>>testPlayerChecksStateVersion >>> TowergameSyncTests(TestCase)>>performTest >>> [ self setUp. >>> self performTest ] in TowergameSyncTests(TestCase)>>runCase >>> BlockClosure>>ensure: >>> TowergameSyncTests(TestCase)>>runCase >>> [ aTestCase runCase ] in [ [ aTestCase runCase ] >>> on: Halt >>> do: [ :halt | >>> "if test was halted we should resume all background failures >>> to debug all of them together with test process" >>> failedProcesses keysDo: #resume. >>> halt pass ] ] in >>> TestExecutionEnvironment>>runTestCaseSafelly: >>> BlockClosure>>on:do: >>> [ [ aTestCase runCase ] >>> on: Halt >>> do: [ :halt | >>> "if test was halted we should resume all background failures >>> to debug all of them together with test process" >>> failedProcesses keysDo: #resume. >>> halt pass ] ] in >>> TestExecutionEnvironment>>runTestCaseSafelly: >>> BlockClosure>>on:do: >>> TestExecutionEnvironment>>runTestCaseSafelly: >>> [ self runTestCaseSafelly: aTestCase ] in [ [ self runTestCaseSafelly: >>> aTestCase ] >>> ensure: [ testCompleted := true. >>> watchDogSemaphore signal ]. "signal that test case >>> completes" >>> self checkForkedProcesses ] in TestExecutionEnvironment>>runTestCase: >>> BlockClosure>>ensure: >>> [ [ self runTestCaseSafelly: aTestCase ] >>> ensure: [ testCompleted := true. >>> watchDogSemaphore signal ]. "signal that test case >>> completes" >>> self checkForkedProcesses ] in TestExecutionEnvironment>>runTestCase: >>> BlockClosure>>ifCurtailed: >>> TestExecutionEnvironment>>runTestCase: >>> [ testEnv runTestCase: aTestCase ] in >>> DefaultExecutionEnvironment>>runTestCase: >>> [ self value: anExecutionEnvironment. >>> anExecutionEnvironment activated. >>> aBlock value ] in CurrentExecutionEnvironment class>>activate:for: >>> BlockClosure>>ensure: >>> CurrentExecutionEnvironment class>>activate:for: >>> TestExecutionEnvironment(ExecutionEnvironment)>>beActiveDuring: >>> DefaultExecutionEnvironment>>runTestCase: >>> CurrentExecutionEnvironment class>>runTestCase: >>> TowergameSyncTests(TestCase)>>runCaseManaged >>> [ aTestCase announce: TestCaseStarted withResult: self. >>> aTestCase runCaseManaged. >>> aTestCase announce: TestCaseEnded withResult: self. >>> self addPass: aTestCase ] in TestResult>>runCaseForDebug: >>> BlockClosure>>on:do: >>> TestResult>>runCaseForDebug: >>> [ result runCaseForDebug: self ] in TowergameSyncTests(TestCase)>>debug >>> BlockClosure>>ensure: >>> TowergameSyncTests(TestCase)>>debug >>> [ :each | >>> each debug. >>> self announceTest: each. >>> self changed: each ] in [ self tests >>> do: [ :each | >>> each debug. >>> self announceTest: each. >>> self changed: each ] ] in TestSuite>>debug >>> OrderedCollection>>do: >>> [ self tests >>> do: [ :each | >>> each debug. >>> self announceTest: each. >>> self changed: each ] ] in TestSuite>>debug >>> BlockClosure>>ensure: >>> TestSuite>>debug >>> [ :aSuite | aSuite debug ] in TestRunner>>debugSuite: >>> BlockClosure>>cull: >>> BlockClosure>>cull:cull: >>> [ aBlock cull: aTestSuite cull: result ] in TestRunner>>executeSuite:as: >>> BlockClosure>>ensure: >>> TestRunner>>executeSuite:as: >>> TestRunner>>debugSuite: >>> TestRunner>>debug: >>> TestRunner>>errorSelected: >>> PluggableListMorph>>changeModelSelection: >>> PluggableListMorph>>mouseUpOnSingle: >>> PluggableListMorph>>mouseUp: >>> PluggableListMorph(Morph)>>handleMouseUp: >>> MouseButtonEvent>>sentTo: >>> PluggableListMorph(Morph)>>handleEvent: >>> MorphicEventDispatcher>>dispatchDefault:with: >>> MorphicEventDispatcher>>handleMouseUp: >>> MouseButtonEvent>>sentTo: >>> [ ^ anEvent sentTo: self ] in >>> MorphicEventDispatcher>>dispatchEvent:with: >>> BlockClosure>>ensure: >>> MorphicEventDispatcher>>dispatchEvent:with: >>> PluggableListMorph(Morph)>>processEvent:using: >>> PluggableListMorph(Morph)>>processEvent: >>> PluggableListMorph>>handleFocusEvent: >>> [ ActiveHand := self. >>> ActiveEvent := anEvent. >>> result := focusHolder >>> handleFocusEvent: (anEvent transformedBy: (focusHolder >>> transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: >>> BlockClosure>>on:do: >>> WorldMorph(PasteUpMorph)>>becomeActiveDuring: >>> HandMorph>>sendFocusEvent:to:clear: >>> HandMorph>>sendEvent:focus:clear: >>> HandMorph>>sendMouseEvent: >>> HandMorph>>handleEvent: >>> HandMorph>>processEventsFromQueue: >>> HandMorph>>processEvents >>> [ :h | >>> self activeHand: h. >>> h processEvents. >>> self activeHand: nil ] in WorldState>>doOneCycleNowFor: >>> Array(SequenceableCollection)>>do: >>> WorldState>>handsDo: >>> WorldState>>doOneCycleNowFor: >>> WorldState>>doOneCycleFor: >>> WorldMorph>>doOneCycle >>> WorldMorph class>>doOneCycle >>> [ [ WorldMorph doOneCycle. >>> Processor yield. >>> false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess >>> [ self value. >>> Processor terminateActive ] in BlockClosure>>newProcess >>> >>> >>> > >

Aug. 14, 2017

S8 Smalltalk tools - Android

by Elvio Fernandez

We've published an enviroment for social development as an Android Application! Now we have support for Object Technology on Android devices. https://play.google.com/store/apps/details?id=net.smalltalking.s8.jx8 Greetings Elvio

Aug. 14, 2017