- Pharo-dev - lists.pharo.org

Pharo behind ALLSTOCKER marketplace
by Masashi UMEZAWA Aug. 17, 2017

Aug. 17, 2017

Hi all, >From Torsten, I've received a request to post about some technical details of ALLSTOCKER (http://pharo.org/success/AllStocker) . I hope these notes will be interesting to Pharo web developers. - Seaside / Teapot We are using Seaside as a main framework for ALLSTOCKER marketplace. Seaside's component architecture is great for extending application in an organized way. ALLSTOCKER prototype was originally composed of only 3 class categories. Now these were gradually grown to 70 categories. But we still feel that they are manageable. We also use Teapot for building Web-based API in a quick way. Recently we've built webhook handlers for integration with other services. - Templating with Mustaside We need a lot of responsive-design web pages for supporting various mobile devices. (It is important especially for Southeast Asian countries, where tablets are popular than PCs). We would like to adopt existing Twitter Bootstrap templates for saving time. So, Mustaside was our choice. http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside Before Mustaside, there were a lot of noisy #div: sends in our code. Now they are gone. - Localization Our business target is world-wide. So localization is very important topic. Currently ALLSTOCKER supports 4 languages and we will add Chinese languages soon. Translation strings are not only in Smalltalk code, but also in Mustache templates. So we selected Soup for extracting translatable strings in those templates. http://smalltalkhub.com/#!/~PharoExtras/Soup For managing translations, we use Gettext package. http://smalltalkhub.com/#!/~PharoExtras/Gettext - Databases For transactional data, we chose Glorp. Although there are mapping costs, we prefer RDB (Postgres). It is reliable for handling precious order-related data. However, for supporting complex search of machines, we use Neo4j - a graph database. It supports very powerful query language called Cypher. We can avoid complex table joins and get aggregated results faster. http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt - Keyword search ALLSTOCKER supports free keyword search. We selected Elasticsearch for search-engine. Elasticsearch has elaborated searching facilities and those are easily accessible via REST API. We have extended the existing Elasticsearch client for Pharo 5. https://github.com/newapplesho/elasticsearch-smalltalk - Deployment We are using AWS Elastic Load Balancer and running Nginx as a front-end web server. Two back-end Pharo images are running and load-balanced with sticky sessions. It was sort of difficult to find the appropriate simultaneous number of database connections and Pharo processes. We feel ALLSTOCKER is pretty stable for now, but we need to adjust more for expanding our services. Best regards, -- [:masashi | ^umezawa]

8 7

Can we have subclasses of Process?
by Denis Kudriashov Aug. 17, 2017

Aug. 17, 2017

Hi. Is it allowed to subclass Process? I remember that there were some problems with it but I could not find any information. Generally I think about system processes which can be represented by concrete subclasses. For example explicit UIProcess can be used to remove many #isUIProcess conditions from system. Best regards, Denis

5 4

eventual crashes pharo vm
by henry Aug. 17, 2017

Aug. 17, 2017

Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers http://www.squeaksource.com/TurquoiseTesting.html - HH

3 13

Adding build info into pharo runtime
by Guillermo Polito Aug. 17, 2017

Aug. 17, 2017

Hi all, as asked by Torsten, I spent some time adding build info into the pharo runtime. https://pharo.fogbugz.com/f/cases/20321/Add-build-number-to-SystemVersion https://github.com/pharo-project/pharo/pull/212 Tests are green https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… The built image can be tested from here: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… The build info is also shown in the About dialog. We show the same than what is found in built pharo artifacts in the file server. [image: Inline image 2] Please review or go on and propose a change based on that. Remember that I'm leaving on vacations tomorrow. Hope this is useful, Guille -- 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

2 1

Issue that may break Epicea
by Stephane Ducasse Aug. 17, 2017

Aug. 17, 2017

Hi martin https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile https://github.com/pharo-project/pharo/pull/133

3 4

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default
by Jimmie Houchin Aug. 17, 2017

Aug. 17, 2017

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." > >

10 14

Path * '' vs. Path workingDirectory
by Alistair Grant Aug. 17, 2017

Aug. 17, 2017

Hi All, Is there any practical difference between (Path * '') and (Path workingDirectory)? Their internal representation is different: - (Path * '') has one empty segment - Path workingDirectory has no segments But as far as I can tell they are otherwise the same: | fs frEmpty frWD | fs := FileSystem disk. frEmpty := FileReference fileSystem: fs path: (Path * ''). frWD := FileReference fileSystem: fs path: Path workingDirectory. String streamContents: [ :stream | stream << 'frEmpty: '; << frEmpty printString; cr; << 'frWD: '; << frWD printString; cr; << '= : '; << (frEmpty absolutePath = frWD absolutePath) printString; cr. ] 'frEmpty: "File @ " frWD: "File @ ." = : true ' Cheers, Alistair

2 3

Anybody using Orca Smalltalk to JavaScript?
by Frank Berger Software Aug. 17, 2017

Aug. 17, 2017

Hello, the available documentation on Orca looks brilliant and the source, Hasso-Plattner-Institut in Potsdam, has an excellent reputation. It looks all very professional. I am therefore most suprised that I cannot find any tracks of usage of Orca, neither here, nor elsewhere on the net, and not even any serious discussions. Does anybody here have practical experience with Orca? Critics? Recommendations? My goal is to use it for a real-life business application rather than the ST2JS, which would be the second alternative. All of my server software is written in Smalltalk anyway. Thank you in advance for any comment. Frank

15 38

FileSystem fix integration
by Stephane Ducasse Aug. 17, 2017

Aug. 17, 2017

Hi alistair I will go over all the FS changes and push them in Pharo 70. I'm learning the process to integrate fixes and I attract bugs :) Stef

4 23

Is there some RSS parser updated around?
by Mariano Martinez Peck Aug. 16, 2017

Aug. 16, 2017

Hi guys, All the RSS parsers I found are all quite outdated...does someone have an updated one? I want to parse RSS and then display it within Seaside (to render kind of company news). Thanks in advance, -- Mariano http://marianopeck.wordpress.com

1 0