- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] large images

by Eliot Miranda

Hi Both, let me try again :-/ > On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Nice! > > I put Eliot in CC :). > > @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). > > Doru > > >> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: >> >> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. I guess the scan could be folded into the gc. This is a long time to wait! The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. Both squeak and pharo communities could do well to discuss this and agree on an approach. >> >> >> John Brant > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Esteban Lorenzano

> On 14 Oct 2016, at 16:26, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them ânormalisation methodsâ: they are meant to translate names into something we can interpretâ¦ there is also some like that in the menu building if I remember well :P > > And here idea to slowly remove ~Icon or ~Form suffix from icons names? yes :)

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them > ânormalisation methodsâ: they are meant to translate names into something > we can interpretâ¦ there is also some like that in the menu building if I > remember well :P > And here idea to slowly remove ~Icon or ~Form suffix from icons names?

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Esteban Lorenzano

yes, that was me providing a compatibility/traduction layer :) you will find a couple more of them in the image. I call them ânormalisation methodsâ: they are meant to translate names into something we can interpretâ¦ there is also some like that in the menu building if I remember well :P Esteban > On 14 Oct 2016, at 15:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Oh!!! I just found this method: > > iconNamed: aSymbol ifNone: aBlock > > self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. > "Trying the old way" > > ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ > self icons > at: (aSymbol allButLast: 4) asSymbol > ifPresent: [ :icon | ^ icon ] > ]. > > ^ aBlock value > > > > 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > Denis > You can have a look the changes I did. There is more work to be done but I started. > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 <https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4> > Done. New slice committed >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

Oh!!! I just found this method: iconNamed: aSymbol ifNone: aBlock self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. "Trying the old way" ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ self icons at: (aSymbol allButLast: 4) asSymbol ifPresent: [ :icon | ^ icon ] ]. ^ aBlock value 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Denis >> >> You can have a look the changes I did. There is more work to be done but >> I started. >> >> https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 >> > > Done. New slice committed >

Oct. 14, 2016

Re: [Pharo-dev] Path >> fullName should not be the same as printString

by Damien Pollet

While we're at it, canonicalizing paths at creation time seems wrong also: First because those two expressions do not return the same thing: Path from: 'a/b/c/../d' Path * / 'a' / 'b' / 'c' / '..' / 'd' Second because if c happens to be a symlink, then the operating system will not find the same thing as Pharo. The semantics is that you follow the symlink first, and follow .. in the directory you end up in. So that goes to the parent of the actual directory pointed to by the symlink, not back one level in the path. On 14 October 2016 at 13:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > All this already works (although maybe not perfectly in edge cases). > Consider: > > 'file:///C:/Users/tempfile.txt' asUrl. > > 'file:///C:/Users/tempfile.txt' asUrl asFileReference. > > FileLocator C / 'Users' / 'tmpfile.txt'. > > Where the last two are identical. > > Note that relative file URLs do not exist. > > > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > > > At least Chrome uses this: > > > > file:///C:/Users/tempfile.txt > > > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> > wrote: > > On 10/13/2016 10:35 AM, Damien Pollet wrote: > > Could you give an example what the file:// URLs look like when they > contain a drive letter? > > > > I'm afraid I don't have any Windows machines handy to see what Internet > Explorer does, but as far as I can tell an absolute URL compliant with RFC > 3986 might look something like > > > > file:/c:/foo/bar > > > > A relative URL that fits the URL syntax would be > > > > file:c:/foo/bar > > > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 > currently interact. > > > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it > directly addresses Windows file naming. In appendix B.2, it says > > > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > > letter (e.g. "c:") as the first path segment. Some implementations > leave the leading slash off before the drive letter. " > > > > and appendix C.1 deals with DOS file paths. > > > > > > I hope this is more helpful than it is confusing. > > > > Regards, > > > > -Martin > > > > > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 14, 2016

Re: [Pharo-dev] Path >> fullName should not be the same as printString

by Sven Van Caekenberghe

All this already works (although maybe not perfectly in edge cases). Consider: 'file:///C:/Users/tempfile.txt' asUrl. 'file:///C:/Users/tempfile.txt' asUrl asFileReference. FileLocator C / 'Users' / 'tmpfile.txt'. Where the last two are identical. Note that relative file URLs do not exist. > On 14 Oct 2016, at 13:28, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > At least Chrome uses this: > > file:///C:/Users/tempfile.txt > > On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> wrote: > On 10/13/2016 10:35 AM, Damien Pollet wrote: > Could you give an example what the file:// URLs look like when they contain a drive letter? > > I'm afraid I don't have any Windows machines handy to see what Internet Explorer does, but as far as I can tell an absolute URL compliant with RFC 3986 might look something like > > file:/c:/foo/bar > > A relative URL that fits the URL syntax would be > > file:c:/foo/bar > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 currently interact. > > The discussion in this proposed RFC is somewhat interesting: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it directly addresses Windows file naming. In appendix B.2, it says > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > letter (e.g. "c:") as the first path segment. Some implementations leave the leading slash off before the drive letter. " > > and appendix C.1 deals with DOS file paths. > > > I hope this is more helpful than it is confusing. > > Regards, > > -Martin > > >

Oct. 14, 2016

Re: [Pharo-dev] Path >> fullName should not be the same as printString

by Gabriel Cotelli

At least Chrome uses this: file:///C:/Users/tempfile.txt On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure <martin(a)hand2mouse.com> wrote: > On 10/13/2016 10:35 AM, Damien Pollet wrote: > >> Could you give an example what the file:// URLs look like when they >> contain a drive letter? >> >> I'm afraid I don't have any Windows machines handy to see what Internet > Explorer does, but as far as I can tell an absolute URL compliant with RFC > 3986 might look something like > > file:/c:/foo/bar > > A relative URL that fits the URL syntax would be > > file:c:/foo/bar > > But I'm finding it difficult to tell precisely how RFCs 1738 and 3986 > currently interact. > > The discussion in this proposed RFC is somewhat interesting: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02, as it > directly addresses Windows file naming. In appendix B.2, it says > > "When mapping a DOS- or Windows-like file path to a URI, use the drive > letter (e.g. "c:") as the first path segment. Some implementations > leave the leading slash off before the drive letter. " > > and appendix C.1 deals with DOS file paths. > > > I hope this is more helpful than it is confusing. > > Regards, > > -Martin > > >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr>: > Denis > > You can have a look the changes I did. There is more work to be done but I > started. > > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 > Done. New slice committed

Oct. 14, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by Nicolas Passerini

Hi HernÃ¡n, thank you for your report. It would be even nicer if you could report it at https://github.com/npasserini/iceberg/issues I think we might not be far from having Iceberg working on Pharo 5.0. Even we have our tests running on Pharo 6.0 and 5.0 in travis ( https://travis-ci.org/npasserini/iceberg) both for linux and mac. Sadly the tests do not cover the UI and that is why I missed the issue reported by HernÃ¡n. I do not know how hard could it be to have tests for that. But the real problem right now is to have everything running on Windows. That might take a while, maybe next month we will arrive there. On Fri, Oct 14, 2016 at 12:48 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > Ok. IMHO Nicolas if you really want more feedback I think it's worth it to > release it for 5.0, unless 6.0 has dramatically changed :) > Cheers, > > HernÃ¡n > > > 2016-10-13 14:02 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> in principle, Iceberg is meant to work on Pharo6+ >> No idea about backward compatibility (it shouldnât be so hard eitherâ¦) >> >> Esteban >> >> On 13 Oct 2016, at 19:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> Hi Nicolas, >> >> After installing it in Pharo 5.0 (#50761, Win 7) and clicking World Menu >> -> Tools -> Iceberg >> I got the Exception in the screenshot attached. >> >> >> 2016-10-13 9:25 GMT-03:00 Nicolas Passerini <npasserini(a)gmail.com>: >> >>> Hi, we are releasing a new version of Iceberg, with several new features >>> and bugfixes. I would't yet say that is 100% production ready, but it is >>> close, so I want to invite you to test it and provide feedback. >>> >>> You can install it by doing: >>> >>> Metacello new >>> baseline: 'Iceberg'; >>> repository: 'github://npasserini/iceberg'; >>> load. >>> >>> More installation instructions and documentation can be found at >>> https://github.com/npasserini/iceberg. >>> >>> Some of the new features in this version are: >>> - Allow to commit several packages together in the same commit. >>> - Show diffs for incoming and outgoing commits (i.e. before push/pull >>> you can browse the difference between the remote and the local versions). >>> - New History view allows to see any commit in any branch and compare it >>> to the current loaded version. >>> - Better support for interacting code loaded outside Iceberg >>> (smaltalkhub, filetree, gitfiletree, etc). >>> - From the diff view, revert changes or browse them (i.e. open a >>> Nautilus on the changed class/method). >>> - Automatically update presentations on code / repository changes. >>> - Integration with Metacello, i.e. after installing Iceberg you do >>> something like >>> >>> Metacello new >>> baseline: 'TaskIt'; >>> repository: 'github://sbragagnolo/taskit'; >>> load. >>> >>> >>> (By default) it will be loaded using iceberg (there is a setting to >>> avoid it if you prefer traditional behavior. >>> >>> - Improved handling of git errors. >>> - Improved performance for several operations. >>> - Improved documentation. >>> - ... and several bug fixes and other minor improvements (please look at >>> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more >>> details). >>> >>> >>> Please do not hesitate to contact me if you have any doubts. >>> >> >> <IceberError.jpg> >> >> >> >

Oct. 14, 2016