- Pharo-users - lists.pharo.org

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

by Hilaire

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 Thanks Hilaire Le 24/02/2019 Ã 20:55, Hilaire a Ã©critÂ : > Thanks Sven, > > It looks like the same VM I used with the previous bundle. md5sum on the > Pharo executable produced the same check sum. > > Still I packaged one with this bundle, this time I preserved the plugin > lib symlink in the zip archive, if you want to give a try. > > https://www.dropbox.com/s/me1z6prfln1pbe8/DrGeo-mac-19.03a.zip?dl=0 -- Dr. Geo http://drgeo.eu

Feb. 25, 2019

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

by sergio ruiz

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. 25, 2019

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

by S Krish

This is fine: www.bagelconcertfinder.com/zipcodes/{zipCode} Preferred is : *https://......siteName.../boundedContext/resourceInPlural/{resourceId}* So this can be as you state but without _ underscores and "concertBlogging" is identified bounded context for a set of resources https://....siteName../*concertBlogging*/blogs/{blogId} Plurals are recommended. Lots of Style conformance is recommended, stick to REST and not use actions/ verbs in urls et als.. You can break many of the so called rules and still it will work fine for you, but its up to you, to decide what you adhere to and what you define for yourself 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. On Mon, Feb 25, 2019 at 12:13 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Hi, all.. > > I am looking to have a repeatable url so users can save them and share > them.. something like: > > www.bagelconcertfinder.com/zipcode/44805 > > and in my next project, Iâll be doing something like a CMS where you would > get: > > /blog_entries/this-is-the-path > > I am thinking of using REST to flesh out the paths.. > > does this seem reasonable? > > ---- > 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. 25, 2019

Repeateble URLs - REST?

by sergio ruiz

Hi, all.. I am looking to have a repeatable url so users can save them and share them.. something like: www.bagelconcertfinder.com/zipcode/44805 and in my next project, Iâll be doing something like a CMS where you would get: /blog_entries/this-is-the-path I am thinking of using REST to flesh out the paths.. does this seem reasonable? ---- 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. 25, 2019

Re: [Pharo-users] Can't <BlSpace> addChild: <BlSpartaMozCanvasBuilder>

by Tudor Girba

Hi, addChild: expects a BlElement not a canvas. A BlElement draws on a canvas object that is passed to it. SpartaCanvas is an abstract class. If you want to instantiate a canvas, pick one of the subclasses. For example, for MozCanvas, see MozExamples. Cheers, Tudor > On Feb 25, 2019, at 4:55 PM, David Richards <david.i.richards.iii(a)gmail.com> wrote: > > | canvas space node text | > > . BlUniverse reset > > . space := BlSpace new > . space show > . space title: 'Test Space' > . space extent: 800@400 > . space root background: Color lightBlue > . space position: 1@25 > > . canvas := BlSpartaMozCanvasBuilder extent: 400@250 > > . space root addChild: canvas > > This fails. > > Any ideas how to create a Sparta Canvas, to draw some text on? > > -- www.feenk.com "There are no old things, there are only old ways of looking at them."

Feb. 25, 2019

Re: [Pharo-users] What does the Package and Sub-Package comment do?

by Denis Kudriashov

Hi Tim. Behaviour is similar to Pharo 6. When class is selected the comment belongs to the class. If not then it belongs to the package. There is no such thing as a tag comment. I thought the default comment text is clear enough to avoid confusion. But probably it's not as you wrote this mail. So it is a room for improvements. Package comment is managed as a comment of ts manifest class. When you first time add it the manifest class is created. 25 ÑÐµÐ²Ñ. 2019 Ð³. 15:09 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Tim Mackinnon" <tim(a)testit.works> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: Anyone have any thoughts on this? Not sure whether to report a bug or not. > On 22 Feb 2019, at 14:48, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - I notice that you can sort of put comments on packages - but Iâm not sure if this is working or if its supposed to work? > > When I type something it seems to create and extra Manifest tag, and then the comment that I type seems to be the same for the package and all of its sub tags? > > Is this a work in progress? Should Calypso even show a comment for the tags (or is it read only for them - as its the parent). > > Iâm just not clear on what it does, and whether I can programmatically add stuff to it or not? (I was thinking for exercism to store exercise information there - but maybe I will stick to the test class comment) > > Tim

Feb. 25, 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 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. 25, 2019

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

by Tim Mackinnon

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. 25, 2019

How can I the best filter out data and make a collection of paintings

by Roelof Wobben

Feb. 25, 2019

Re: [Pharo-users] JSON keys not quoted?

by Sven Van Caekenberghe

> On 23 Feb 2019, at 03:53, Ben Coman <btc(a)openinworld.com> wrote: > > Just curiousity... Is an idempotent round trip required/expected ? Not necessarily, but symmetry is important and a lack of symmetry is often a possible indication of trouble. Anyway, since the standard is crystal clear that JSON keys/names in objects must be strings, I am enforcing that now. It is not OK to silently generate illegal JSON. https://github.com/svenvc/NeoJSON/commit/c368bbf475f60d564cd3fb708e99b92efe… (And I made the same change to STON in JSON mode) > cheers -ben > > On Sat, 23 Feb 2019 at 05:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Good catch. > > Indeed, JSON keys have to be strings. > > The question is, should the writer convert them for you, or should you simply not use them ? > > I mean, there are many Pharo constructs that cannot be converted to JSON. > > Some could be output to JSON, but you won't be able to read them back in. > > So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. > > In STON, keys can be anything, even complex objects, like in Pharo itself. > > What will you do with { (1@2)->100 } asDictionary in JSON ? > > I have to think about this. > > > On 22 Feb 2019, at 21:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > If you convert a Dictionary with numbers as keys it will produce not > > valid JSON [1], since all object keys must be quoted. > > > > E.g. > > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > > or > > (Dictionary with: 1->'foo') asJson > > > > Should the library generate quoted keys? > > > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > > render the object properly, but NeoJSON does it automatically. > > > > In Javascript this will throw a syntax error: > >> JSON.parse('{1: "foo"}') > > > > And this would generate a quoted key when serialized: > >> JSON.stringify({1: "foo"}) > >> {"1": "foo"} > > > > So my question is: should the library quote whatever you put as key in > > order to produce valid JSON syntax? [2] > > > > Regards. > > > > [1] https://jsonlint.com/ > > [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm > > > > Esteban A. Maringolo > > > >

Feb. 25, 2019