February 2019 - Pharo-users

Re: [Pharo-users] Voyage for Pharo 7

by Roelof Wobben

Feb. 26, 2019

Voyage for Pharo 7

by sergio ruiz

Is the installation for this set up somewhere? I am using the metacello script here: https://github.com/pharo-nosql/voyage and the catalog.. and am getting errors everywhere. Thanks! ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 26, 2019

Re: [Pharo-users] Repeateble URLs - REST?

by S Krish

I would defer to Seaside experts on this, but I would say yes to Seaside REST in general and Teapot REST otherwise if it meets your requirements . I have not worked on them for a long time now. On Mon, Feb 25, 2019 at 2:05 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Gotcha.. > > So, in Seaside, should how should I handle the routes? with Seaside REST? > > On February 25, 2019 at 2:56:49 PM, S Krish ( > krishnamachari.sudhakar(a)gmail.com) wrote: > > https://restfulapi.net/resource-naming/ > <https://restfulapi.net/resource-naming/> > > https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-desi… > > Given the conflicting advices on REST, you can try and adhere to one-two > sources of advice. > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Feb. 26, 2019

Pharo consortium selected for GSOC 2019

by Serge Stinckwich

Dear all, Pharo Consortium has been selected this year as a Google Summer of Code 2019 mentor organization. This is the first time since 2017. I would like to thank other GSOC co-admin Jigyasa Grover and Oleksandr Zaytsev for their commitment and hard work, Peter Uhnak for his help for the website, Alexandre Bergel, Yuriy Tymchuk and StÃ©phane Ducasse for their interactions. We will prepare the call for students soon. We have already a website with a list of subject: http://gsoc.pharo.org/ More subjects can be added, but we will focus on topics that will have the bigger impact on the Pharo community. We will use the #gsoc-planning channel on Discord to discuss. If you have students that might be interested, please let them know about this opportunity. There is #gsoc-students channel for them. Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

Feb. 26, 2019

Re: [Pharo-users] Windows 64bit, long filename issue but after a second load, how to categorise and report this?

by Tim Mackinnon

Iâve been able to find out more information about this - and have now got the full filename and error in question: `'C:/Users/sam/Documents/Pharo/images/exercism-test-run-7.0-32bit/pharo-local/iceberg/dionisiydk/StateSpecs/StateSpecs-DSL-PragmaBasedShouldExpressions-Tests.package/SpecOfShouldExpressionDriverTests.class/instance/testRaiseUnexpectedMessageWhenTooMuchMessages.st': The filename or extension is too long.` So the path is 262 characters long. (hence the error) The package this file is in, is a downstream project prerequisite for PharoWebBrowser - which is dragged in because that project doesn't have different groupings for code and tests (something I am working with Sean to try to get resolved - although Iâm scratching my head on how you can test baselines?). We don't see this in the image in OSX because the included baseline doesn't actually pre-req these pragma based tests? However from below, have I now understood that when we reference a project, we end up cloning the whole repository for that repo on disk (so one big read), and then metacello picks out the relevant files from the baseline. So possibly, this might be some orphaned files/packages in the repo - that iceberg no longer knows about, but git does? The longer term fix is to convert PharoWebBrowser to Tonel and see if we can improve the grouping. Tim > On 25 Feb 2019, at 17:19, Tim Mackinnon <tim(a)testit.works> wrote: > > Iâve created - https://github.com/pharo-vcs/iceberg/issues/1204 > >> On 25 Feb 2019, at 17:12, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Just to add some additional notes on this (and I will also file an issue, as I donât think one has been submitted, and I donât think this is fully down to file path length alone) - >> >> After some more testing, we have also seen the error on Windows 32bit as well (so while easier to get in 64bit, it does occur in 32bit like others have reported). >> >> My real concern however, is that a simple project (which admittedly pulls in a single Filetree prerequisite - PharoWebBrowser) seems to trigger this error - but confusingly references files that donât appear to be in the image. Tracing through PharoWebBrowser - there are some file tree based pre-reques and some that are mcz - and none of them have files like: testRaiseUnexpectedMessageWhenTooMuchMessages.st >> >> And this method is not in the image that gets loaded into OSX. So I am wondering where these long files are coming from? >> >> So yes, while there is a long filename issue - is there another hidden issue underneath all of this where files we arenât even using are getting reference somehow? >> >> Tim >> >>> On 22 Feb 2019, at 00:01, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Some interesting thoughts below - but my understanding is these images are being created by Pharo Launcher , so they should be isolated from one another? >>> >>> I also donât understand why you can load with 32bit (multiple images) but only once with 64bit. Do we load radically different git code with longer paths on 64bit? (Strange isnât it?) >>> >>> Possibly worth caveating this is with 2-3 users so far, and only noticed this pattern with the last one. >>> >>> Also - has anyone created an issue for these path problems - Iâm curious if my results match anything else. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 21 Feb 2019, at 16:01, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>> Tim Mackinnon wrote >>>>> Hi Ben - while I understand the description below - why would it work the >>>>> first time (no errors) and then fail the second time in a fresh image? Are >>>>> we really sure its just down to non-determinism of the load process >>>>> (possibly - but it seems very suspicious to me). There is something more >>>>> fishy about windows going on I suspectâ¦ >>>> >>>> The Iceberg cache path is relative to the image folder, so it's at least >>>> possible to have success in one image, located in C:\Pharo\testImage\, while >>>> another image, reciding in something like >>>> C:\Users\sam\Documents\Pharo\images\exercism-test-run-7.0-32\ , fails to >>>> load the exact same filetree package... >>>> >>>> >>>> Tim Mackinnon wrote >>>>> I will track down the Exercism dependencies to see if any of them are >>>>> FileTree - having said that, on OSX (where it loads cleanly - I would >>>>> expect to be able to find one of those methods in my image - but again I >>>>> canât? They look like valid methods - but why arenât they in my image? Its >>>>> like the load process is downloading other stuff on its own and then not >>>>> loading that into the image? >>>> >>>> Yeaaah, that sounds fishy. >>>> But at least the first method sounds like a test, which may be part of the >>>> packages in the git repo that gets cloned without being loaded by Metacello, >>>> if the Metacello dependency specifies a *Core group which does not include >>>> tests. >>>> >>>> >>>> Tim Mackinnon wrote >>>>> Iâm just worried that we keep blaming windows (and yes its dumb having a >>>>> file length restriction I this day and age) - but maybe we are missing >>>>> another problem too? >>>>> >>>>> Tim >>>> >>>> To be pendantic, (and not of much actual help, sorry :/ ) the problem isn't >>>> really with Windows, which provides API's for getting file info that handle >>>> long paths just fine, but with libgit, which is probably compiled against >>>> some POSIX stat implementation provided by Cygwin/mingw, which does not. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >>> >>> >> >> > >

Feb. 26, 2019

Re: [Pharo-users] Mac OS X test [ smaller image ]

by Sven Van Caekenberghe

> On 26 Feb 2019, at 09:11, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > We reuse the app built for opensmalltalk vm but I fear it is a bit outdated. I tried to update the nib file but this format is not used anymore. It is now replaced by xib file (and I do not know much on OS X UI dev). If you do not need to customize it too much, it should be ok. Christophe, I am going to send you a private email about this.

Feb. 26, 2019

Re: [Pharo-users] Mac OS X test [ smaller image ]

by Christophe Demarey

Hi Hilaire, > Le 25 fÃ©vr. 2019 Ã 21:55, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > > >> On 25 Feb 2019, at 21:41, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> I think I am running out of option. >> >> Since about 10 years, it is the first time I am stuck with Pharo to >> deliver an end user application on Mac. >> >> Any idea? >> >> Can some try on a mac to run as this for any meaningful feedback? >> >> cd ./DrGeo.app >> >> ./Contents/MacOS/Pharo ./Contents/Resources/drgeo.image > > prometheus:DrGeo.app sven$ ./Contents/vm/Pharo ./Contents/Resources/drgeo.image > 2019-02-25 21:49:49.816 Pharo[68128:5223153] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting > > This is not my area of expertise, but you are trying to do this without having a Mac and/or basic Mac developer experience ? > > Those .app bundles are really harder than they look. This is very much related to how macOS works (including virus and malware protection). > > Can't you look at the PharoLauncher for how this should be done ? Maybe the developers working on PharoLauncher can help ? Pharo Launcher mac packaging is available here: https://github.com/pharo-project/pharo-launcher/tree/development/mac You can skip the signing part if not needed. We reuse the app built for opensmalltalk vm but I fear it is a bit outdated. I tried to update the nib file but this format is not used anymore. It is now replaced by xib file (and I do not know much on OS X UI dev). If you do not need to customize it too much, it should be ok. HTP, Christophe https://stackoverflow.com/questions/3726400/what-is-the-difference-between-…

Feb. 26, 2019

Re: [Pharo-users] Display MozCanvas on screen?

by Tudor Girba

Hi, Look for the examples that are shipped with GT/Brick/Bloc/Sparta. The simplest way you play with the canvas is through the inspector. For example, paste this code in a Playground: canvas := BlSpartaMozCanvasBuilder extent: 600@400. canvas fill paint: Color white; path: canvas bounds; draw. path := canvas path moveTo: 150@50; lineTo: 250@250; curveVia: 150@300 to: 50@250; close; finish. canvas stroke paint: Color red; path: path; strokeOptions: (canvas strokeOptions width: 5); draw. canvas Then inspect the result (Cmd+g), and choose the Preview view from the inspector. Here is how it looks like in the new GT Playground: Cheers, Doru > On Feb 25, 2019, at 11:09 PM, David Richards <david.i.richards.iii(a)gmail.com> wrote: > > > | canvas | > > . canvas := BlSpartaMozCanvasBuilder extent: 600@400 > > How do I display this MosCanvas on screen? > > Does anyone know where I can get documentation on how to do graphics in Pharo? The comments in the code are not understandable to a beginner. -- www.feenk.com "We cannot reach the flow of things unless we let go."

Feb. 26, 2019

Google Protobuf and usage of Slots

by Holger Freyther

Hi, from my point of view the pillars of future services are Google protobuf[1] and gRPC. Protobuf can be used for configuration files[2], tracing/logging[3] and storage[4]. gRPC is built on top-of HTTP2 and is using the protobuf IDL and marshaling. Many projects (etcd, envoy, Google Cloud, ...) provide a gRPC based API (and some automatically map this from REST to gRPC) already and I would like to build clients and servers in Pharo. My plan of action is to start with a protobuf compiler/model and then look into binding the gRPC C implementation to Pharo. I have started with gokr's Protobuf code on Smalltalkhub and defined base types and a Slot and could use some help to structure this more nicely. The code is at: https://github.com/zecke/pharo-protobuf and I could use some comments/review of how to use Slots in a significant way (add "type" validation on write, constraint checks, builder pattern?). Given a definition like: syntax = "proto2"; package foo; enum Color { RED = 0; GREEN = 1; BLUE = 2; } message MyMessage { optional Color color = 1; } And an encoded binary message of #[8 2] the following can: PBTestMessage materializeFrom: #[8 2] readStream decode and set the color field. Proper handling of mandatory and repeated fields are missing and decoding the other values, nested messages... :) Looking forward to have some eyes on the code. holger [1] A simple IDL to define structs/enums with marshaller/materializer for a binary protocol, JSON (and yaml). [2] Without having to write a XML/JSON schema and getting validation from the IDL. [3] Many of us log structured to text, then have something like logstash to re-parse, regexp it and dump it into ElasticSearch. With protobuf we can have plain objects end to end for logging. [4] We have FUEL so this is less interesting for us than others but quite interesting if you are mixing Pharo with other implementation languages.

Feb. 26, 2019

Re: [Pharo-users] NeoJSON mapping question

by BrunoBB

Hi, Finally i found a much more acceptable solution :) neoJsonMapping: mapper "Map the receiver from a json with <NeoJSONObjectMapping> <mapper>" mapper for: self do: [ :mapping | mapping mapAccessor: #locator mutator: #setLocator: to: 'booking'. ]. setLocator: aDictionary locator := aDictionary at: '@locator' regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 26, 2019