December 2018 - Pharo-users

Re: [Pharo-users] Problem loading seaside with Zinc

by Vitor Medina Cruz

Oh yes, I thought they were woking on the change of seaside, but it is done: https://github.com/SeasideSt/Seaside/releases/tag/v3.2.5 I put version 3.2.5 of seaside on my baseline and now it works!!! Thanks! On Fri, Dec 14, 2018 at 3:00 PM Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Fri, Dec 14, 2018 at 5:55 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > Did that: > > > > Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository'; > > baseline: 'ZincHTTPComponents'; > > ignoreImage; > > onConflict: [ :ex | ex useIncoming ]; > > onWarning: [ :ex | Transcript crShow: ex ]; > > silently; > > load; > > lock. > > > > Metacello new baseline: 'Employees'; > > repository: 'tonel:///opt/pharo/employeesSource/pharo/'; > > ignoreImage; > > onConflict: [ :ex | ex useIncoming ]; > > onWarning: [ :ex | Transcript crShow: ex ]; > > silently; > > load: #(core). > > > > > > It seems it did the trick, but then I got another error: > > > > Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 --- > https://github.com/svenvc/zinc.git[0327c84] --- > /opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit) > > ...RETRY->Zinc-Seaside > > ...RETRY->Zinc-Seaside > > ...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside > [Zinc-Seaside] in /opt/pharo/pharo-local/package-cache > /opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit) > > > [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > > [ | references nearestReference cachedReference externalReference > mcVersion loadedVersionInfos | > > cachedReference := nil. > > > > Hi, > > I think I read that Seaside changed the Zinc dependency to the one on > github. Could you retry to load it the normal way please? > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

Dec. 14, 2018

Re: [Pharo-users] Usage of String and FileLocator to reference files in ZipArchive (and probably other places)

by Guillermo Polito

Hi Hans, Sorry for the late reply. On Sun, Nov 25, 2018 at 9:30 PM Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > I found a related problem which indicates that the depreciation of > StandardFileStream in favor of File is incomplete and probably premature: > When a ZipArchive is written, in 7.0 it uses > (File named: aFileName) > writeStreamDo: [...] > In 6.1, it uses > StandardFileStream > forceNewFileNamed: aFileName > do: [...] > Well, the equivalent of this is: f := File named: aFileName. f exists ifTrue: [ f delete ]. f writeStreamDo: [...]. or f := File named: aFileName. f writeStreamDo: [ :stream | stream truncate. ... ]. This is, I reckon, slightly more verbose. On the other side I personally think that "forceNewFileNamed:" is not so useful nor general, maybe for scripting purposes. I think that libraries (as Zip does here for example) should use that with care, since silently overriding a file can be considered nasty :). Besides, taking a Pharo5 image, users of forceNewFileNamed: and forceNewFileNamed:do: are few, mostly tests. And several of the users do override a file silently (and dangerously IMHO) since the do not make it explicit to the user :/. Take for example in pharo5 MIMEDocument >> saveToFile: anAbsolutePathString FileStream forceNewFileNamed: anAbsolutePathString do: [ :str | str binary. str nextPutAll: (self contents) ]. or Fuel's FLSqueakPlatform >> fileNamed: aFilename writeStreamDo: aBlock ^ FileStream forceNewFileNamed: aFilename do: [ :stream | stream binary. aBlock value: stream ] which override the file but the method name does not indicate it. What if the file being overwritten had important data? which is a small but significant difference leading to corrupted zip > archives when overwriting existing files. File does not have equivalent > protocol to #forceNewFileNamed... so it is pretty likely that there are > more > bugs creeping there. Upon a cursory inspection I see that for example > FLFileStreamStrategy will suffer from the same problem when writing to > existing files. > > Is there any documentation on the reasoning of depreciating > StandardFileStream and who is working on this? I'm really new to pharo > development... Submitting "patches" without knowing the original design > rationale seems not very productive. > I've made part of the effort myself, Sven did a bit part too, and many other people whose names aren't coming out of the top of my head (sorry!). Part of the migration guide is here: https://pharoweekly.wordpress.com/2018/03/19/new-files-in-pharo-migration-g… Paver wrote another one that I cannot find right now. There are many emails around discussing the rationale behind this. But in a couple of words the reason was cleaning up. We had for example the concerns of data encoding and buffering repeated between sockets and file management. And also this was using subclasses, which tend to explode with combinations. We refactored this to use a decorator schema which is far more composable and modular, and lets us reuse cross cutting concerns between memory streams, file streams, sockets, etc. Guille

Dec. 14, 2018

Re: [Pharo-users] Problem loading seaside with Zinc

by Cyril Ferlicot

On Fri, Dec 14, 2018 at 5:55 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Did that: > > Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository'; > baseline: 'ZincHTTPComponents'; > ignoreImage; > onConflict: [ :ex | ex useIncoming ]; > onWarning: [ :ex | Transcript crShow: ex ]; > silently; > load; > lock. > > Metacello new baseline: 'Employees'; > repository: 'tonel:///opt/pharo/employeesSource/pharo/'; > ignoreImage; > onConflict: [ :ex | ex useIncoming ]; > onWarning: [ :ex | Transcript crShow: ex ]; > silently; > load: #(core). > > > It seems it did the trick, but then I got another error: > > Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 --- https://github.com/svenvc/zinc.git[0327c84] --- /opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit) > ...RETRY->Zinc-Seaside > ...RETRY->Zinc-Seaside > ...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside [Zinc-Seaside] in /opt/pharo/pharo-local/package-cache /opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit) > [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | > cachedReference := nil. > Hi, I think I read that Seaside changed the Zinc dependency to the one on github. Could you retry to load it the normal way please? > > -- Cyril Ferlicot https://ferlicot.fr

Dec. 14, 2018

Re: [Pharo-users] Problem loading seaside with Zinc

by Vitor Medina Cruz

Did that: Metacello new repository: 'github://svenvc/zinc:v3.0.1/repository'; baseline: 'ZincHTTPComponents'; ignoreImage; onConflict: [ :ex | ex useIncoming ]; onWarning: [ :ex | Transcript crShow: ex ]; silently; load; lock. Metacello new baseline: 'Employees'; repository: 'tonel:///opt/pharo/employeesSource/pharo/'; ignoreImage; onConflict: [ :ex | ex useIncoming ]; onWarning: [ :ex | Transcript crShow: ex ]; silently; load: #(core). It seems it did the trick, but then I got another error: Fetched -> Zinc-HTTP-SvenVanCaekenberghe.1542912596 --- https://github.com/svenvc/zinc.git[0327c84] --- /opt/pharo/pharo-local/iceberg/svenvc/zinc/repository (Libgit) ...RETRY->Zinc-Seaside ...RETRY->Zinc-Seaside ...FAILED->Zinc-Seaside[31mCould not resolve: Zinc-Seaside [Zinc-Seaside] in /opt/pharo/pharo-local/package-cache /opt/pharo/pharo-local/iceberg/SeasideSt/Seaside/repository (Libgit) [0mMetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: [ | references nearestReference cachedReference externalReference mcVersion loadedVersionInfos | cachedReference := nil. On Fri, Dec 14, 2018 at 11:07 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > You can use the lock API in Metacello to use the dependency you want, >> ignoring the ones defined in the baselines. >> > > You mean loading Zinc with lock before I load my project? > > On Wed, Dec 12, 2018 at 5:21 PM Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> You can use the lock API in Metacello to use the dependency you want, >> ignoring the ones defined in the baselines. >> >> On Wed, Dec 12, 2018 at 4:16 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >>> I can't depend on https://github.com/svenvc/zinc because this is a >>> transitive dependency, my baseline depends of seaside that depends of Zinc. >>> Is there a way to exclude Zinc dependency from Seaside so that I can force >>> a Zinc dependency definition of my baseline? >>> >>> On Wed, Dec 12, 2018 at 5:08 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 12 Dec 2018, at 18:56, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>>> wrote: >>>> > >>>> > Note it is trying to reach http://mc.stfx.eu/ZincHTTPComponents, >>>> which don't seems to be hosting Zinc anymore. Since these are transitive >>>> dependencies, I tried to define Zinc in the root of my baseline, as I did >>>> with seaside (magritte baseline had some problem with it), but the same >>>> error >>>> >>>> Yes, that machine is partially down, the mc part will come up later, >>>> sorry. See my earlier message. >>>> >>>> The best is to depend on https://github.com/svenvc/zinc using the >>>> baseline. >>>> >>>> >>>>

Dec. 14, 2018

Re: [Pharo-users] Playing with Pharo 7

by Konrad Hinsen

On 26/11/2018 21:47, Cyril Ferlicot D. wrote: > There is also a recent guide here: > https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/… > > I don't know if it is more beginner friendly. Feedback is welcome. I did the ultimate test: I wrote my own Baseline using nothing but the information from that document. It worked the first time I loaded it into a new image! The main open question left by the guide is how to find the URLs to your dependencies. For packages from GitHub that is not too difficult, as the packages' installation instructions provide the URL. But it took me a while to figure out the URL for XMLParser, which I had installed via the Catalog Browser. In the end I searched for XMLParser on the Web site of smalltalkhub, where I found the URL. Konrad.

Dec. 14, 2018

Re: [Pharo-users] chooseExistingFileReference:extensions:path:preview returning wrong FileReference?

by Guillermo Polito

Hi all, I've created issue https://pharo.fogbugz.com/f/cases/22772/chooseExistingFileReference-extensi… And proposed a single-line fix: https://github.com/pharo-project/pharo/pull/2075 I've tested those scenarios and it was working but some more testing would not hurt :) Guille On Tue, Dec 11, 2018 at 11:15 PM Ben Coman <btc(a)openinworld.com> wrote: > https://pharo.fogbugz.com > > On Wed, 12 Dec 2018 at 01:54, Arturo Zambrano <arturo.zambrano(a)gmail.com> > wrote: > >> Should I report a bug? If so please send me the link to thw issue tracker >> >> On Tue, 11 Dec 2018, 13:05 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: >> >>> I confirm that this does indeed seem to be a problem, weird. >>> >>> > On 11 Dec 2018, at 16:53, Arturo Zambrano <arturo.zambrano(a)gmail.com> >>> wrote: >>> > >>> > Hi All, >>> > I'm replacing a deprecated call by this: >>> > UIManager default >>> chooseExistingFileReference:extensions:path:preview:. >>> > >>> > The returned fileRefence does not point the actual file selected by >>> the user (if the file was chosen navigating to other directories than the >>> default). >>> > For example: >>> > >>> > UIManager default chooseExistingFileReference:'Title' >>> extensions:#('pdf') path: './' preview: nil >>> > >>> > <image.png> >>> > >>> > Inspect the result: >>> > <image.png> >>> > >>> > >>> > >>> > It seems to be a bug, or maybe there is any other way to call the >>> dialog. >>> > >>> > Any pointer is welcome. >>> > >>> > TIA >>> > >>> > >>> > >>> >>> >>> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

Dec. 14, 2018

Re: [Pharo-users] Problem loading seaside with Zinc

by Vitor Medina Cruz

> > You can use the lock API in Metacello to use the dependency you want, > ignoring the ones defined in the baselines. > You mean loading Zinc with lock before I load my project? On Wed, Dec 12, 2018 at 5:21 PM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > You can use the lock API in Metacello to use the dependency you want, > ignoring the ones defined in the baselines. > > On Wed, Dec 12, 2018 at 4:16 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> I can't depend on https://github.com/svenvc/zinc because this is a >> transitive dependency, my baseline depends of seaside that depends of Zinc. >> Is there a way to exclude Zinc dependency from Seaside so that I can force >> a Zinc dependency definition of my baseline? >> >> On Wed, Dec 12, 2018 at 5:08 PM Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> >>> >>> > On 12 Dec 2018, at 18:56, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> > >>> > Note it is trying to reach http://mc.stfx.eu/ZincHTTPComponents, >>> which don't seems to be hosting Zinc anymore. Since these are transitive >>> dependencies, I tried to define Zinc in the root of my baseline, as I did >>> with seaside (magritte baseline had some problem with it), but the same >>> error >>> >>> Yes, that machine is partially down, the mc part will come up later, >>> sorry. See my earlier message. >>> >>> The best is to depend on https://github.com/svenvc/zinc using the >>> baseline. >>> >>> >>>

Dec. 14, 2018

Re: [Pharo-users] glamorous toolkit: v0.4.0

by Richard Sargent

Wow!!! On Thu, Dec 13, 2018, 18:49 Tudor Girba <tudor(a)tudorgirba.com wrote: > Hi, > > Things are moving fast in the glamorous land. We now reached v0.4.0: > https://gtoolkit.com > > There are several significant advances in this version. The first thing to > note is that v0.4.0 is a reproducible version that can be loaded with: > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit:v0.4.0/src'; > load. > https://github.com/feenkcom/gtoolkit/releases/tag/v0.4.0 > > The version was created with Releaser the new member of GT that is able to > release deeply nested projects: > https://twitter.com/girba/status/1073407418460225536 > > > The rest of the environment has seen a few key changes as well: > > - Documenter received support for dynamic markup edit. This is an almost > magic ability that makes the markup appear when the cursor nears the > markup. With this we have reached a seamless experience that supports both > viewing without markup and editing on demand. > https://twitter.com/feenkcom/status/1067879286143676419 > > - Playground uses Coder and snippets are now collapsable. > https://twitter.com/feenkcom/status/1070806168459767809 > > - The Inspector updates when the code changes. > https://twitter.com/feenkcom/status/1072581283925159936 > https://twitter.com/feenkcom/status/1072107898900238337 > > - The Meta view from Inspector was enhanced to show the super classes and > method categories, each of these act list filters. On top of that, we can > also filter methods by name. > https://twitter.com/feenkcom/status/1072223641583149057 > > A more complete list of issues we addressed is found here: > https://github.com/feenkcom/gtoolkit/milestone/2?closed=1 > > > Please do let us know what you think .. and, of course, what you feel. > > Have fun, > The feenk team > > > > -- > www.feenk.com > > âHow do you feenk today?" >

Dec. 14, 2018

glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Things are moving fast in the glamorous land. We now reached v0.4.0: https://gtoolkit.com There are several significant advances in this version. The first thing to note is that v0.4.0 is a reproducible version that can be loaded with: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit:v0.4.0/src'; load. https://github.com/feenkcom/gtoolkit/releases/tag/v0.4.0 The version was created with Releaser the new member of GT that is able to release deeply nested projects: https://twitter.com/girba/status/1073407418460225536 The rest of the environment has seen a few key changes as well: - Documenter received support for dynamic markup edit. This is an almost magic ability that makes the markup appear when the cursor nears the markup. With this we have reached a seamless experience that supports both viewing without markup and editing on demand. https://twitter.com/feenkcom/status/1067879286143676419 - Playground uses Coder and snippets are now collapsable. https://twitter.com/feenkcom/status/1070806168459767809 - The Inspector updates when the code changes. https://twitter.com/feenkcom/status/1072581283925159936 https://twitter.com/feenkcom/status/1072107898900238337 - The Meta view from Inspector was enhanced to show the super classes and method categories, each of these act list filters. On top of that, we can also filter methods by name. https://twitter.com/feenkcom/status/1072223641583149057 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/2?closed=1 Please do let us know what you think .. and, of course, what you feel. Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Dec. 14, 2018

Re: Pharo 7 under Linux

by John Kimber

Hi, I recently installed 70 build 1384 under Mint 19. Seems to be working fine. HTH, john -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 14, 2018