- Pharo-users - lists.pharo.org

Re: [Pharo-users] Teapot session

by Alistair Grant

Hi Phil, On Mon, Jun 19, 2017 at 09:07:23PM +0200, phil(a)highoctane.be wrote: > Try Ctl-q or Cmd-q after having typed a few chars. Continue until you get a > match. > > Works in 6.0 > > Phil Thanks! I wasn't aware of this gem. Cheers, Alistair

June 20, 2017

Re: [Pharo-users] UUIDGenerator

by Stephane Ducasse

May be you should have a look at the Pharo mooc. Because we spent 8 months producing videos. This is free and in two days you can cherry pick what you want. Students like it a lot. Stef On Mon, Jun 19, 2017 at 1:39 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > I didn't know about the Spotter. That is so frickin' cool!!! > > Thanks. > > > philippeback wrote >> Spotting for hex is hardly complex. >> >> Shift-Enter hex #im >> >> --> implementors of hex, first one I see is in ByteArray. >> >> Shit-Enter hex #se >> >> --> senders of hex. First one is a test in ByteArray >> >> testHex >> "self debug: #testHex" >> self assert: #[122 43 213 7] hex = '7a2bd507'. >> self assert: #[151 193 242 221 249 32 153 72 179 41 49 154 48 193 99 134] >> hex = '97c1f2ddf9209948b329319a30c16386'. >> self assert: (ByteArray readHexFrom: '7A2BD507') = #[122 43 213 7]. >> self assert: (ByteArray readHexFrom: '7a2bd507') = #[122 43 213 7]. >> >> From this test, one can spot readHexFrom: which uses lowercase or >> uppercase >> for reading. >> >> And asUppercase, Shift-Enter upper, scrolll down as bit, find >> String>>#asUppercase >> >> Spotter is really great at finding stuff, and coupled with tests and >> examples it helps in building understanding. >> >> Agreed, this is not the same as looking for stuff as in, say, Java or >> Python. I find it better in the long run still. >> >> Phil >> >> On Sat, Jun 17, 2017 at 9:23 PM, horrido < > >> horrido.hobbies@ > >> > wrote: >> >>> Message 'next' is not understood. >>> >>> But yes, >>> >>> UUID new hex asUppercase >>> >>> works fine. >>> >>> This is what happens when there is inadequate documentation: you end up >>> doing things the *hard* way. >>> >>> Thanks. >>> >>> >>> >>> Sven Van Caekenberghe-2 wrote >>> > Why not just >>> > >>> > UUIDGenerator default next hex asUppercase. >>> > >>> > Or even >>> > >>> > UUID new hex asUppercase. >>> > >>> > ? >>> > >>> > Since you are using #generateBytes:forVersion: (which is an internal >>> > method BTW), you must be working in an older Pharo image (older than >>> 6). >>> > We replaced the UUIDGenerator class, the class comment in from the >>> newer >>> > version. >>> > >>> >> On 17 Jun 2017, at 16:27, horrido < >>> >>> > horrido.hobbies@ >>> >>> > > wrote: >>> >> >>> >> Okay, I figured it out. Here's my method: >>> >> >>> >> generateUUID >>> >> | aStream hex s x | >>> >> hex := '0123456789ABCDEF'. >>> >> x := ByteArray new: 16. >>> >> UUIDGenerator default generateBytes: x forVersion: 4. >>> >> s := String new: 32. >>> >> aStream := WriteStream on: s. >>> >> x do: [ :each | aStream nextPut: (hex at: each // 16 + 1). >>> >> aStream nextPut: (hex at: each \\ 16 + 1) ]. >>> >> ^ s >>> >> >>> >> Works like a charm. It would've been nice if a similar example was >>> >> available >>> >> /somewhere/ on the web. >>> >> >>> >> >>> >> >>> >> -- >>> >> View this message in context: >>> >> http://forum.world.st/UUIDGenerator-tp4951725p4951731.html >>> >> Sent from the Pharo Smalltalk Users mailing list archive at >>> Nabble.com. >>> >> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/UUIDGenerator- >>> tp4951725p4951743.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >>> > > > > > > -- > View this message in context: http://forum.world.st/UUIDGenerator-tp4951725p4951844.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 20, 2017

Re: [Pharo-users] Finding files in Pharo

by Alistair Grant

On Tue, Jun 20, 2017 at 04:22:31AM -0300, Hern??n Morales Durand wrote: > > > 2017-06-20 3:14 GMT-03:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Hernan, > > On Mon, Jun 19, 2017 at 09:23:35PM -0300, Hern??n Morales Durand wrote: > > I took the time to review FileSystemDirectoryEntry. > > > > UNIX has 3 types of timestamps > > > > -The access time is the last time when the content was accessed. > > -The modification time is last time when the content was modified. > > -The change time is the last time when the metadata was modified. > > > > FileSystemDirectoryEntry>>creationTime > > This is wrong because there is no such thing as creation time in UNIX. > > Several linux file systems do support creation time, called birth time, > but my understanding is that there is no standard way to retrieve the > birth time commonly available and cross platform. > > > > Thanks for the update, I checked and creation time seems not required by POSIX. > > > > I checked in Linux chmod'ing an empty file and #creationTime displays the > chmod > > "change time". > > Then added content to the file > > > > echo prueba >> test1.txt > > > > And both "creation" and "modification" instance variables were updated. > > > > I couldn't find #accessTime method to get the last timestamp of last > access. > > Linux kernel 4.11 introduced statx(), which adds creation time, but I > don't know if it will be adopted by BSD or MacOS. > > The patches I mentioned earlier and plan for Pharo 7 add support for all > 4 timestamps (creation, change, modification, access). Which fields get > populated depends on the platform. There's a #hasCreationTime flag > which allows you to distinguish between the real creation time and the > change time. > > > > Maybe #creationTime should answer nil or raise an exception if not supported by > underlying file system. > > It would be nice to has full support for tags. If this were new behaviour I would raise an exception, but currently my version of #creationTime continues to return the change time for backward compatibility (it also seems to be common behaviour on Posix systems). The #hasCreationTime flag is there for applications that want to be specific in their behaviour. I'm open to changing this if there is sufficient support or a good enough argument. Cheers, Alistair

June 20, 2017

Re: [Pharo-users] Finding files in Pharo

by HernÃ¡n Morales Durand

2017-06-20 3:14 GMT-03:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Hernan, > > On Mon, Jun 19, 2017 at 09:23:35PM -0300, Hern??n Morales Durand wrote: > > I took the time to review FileSystemDirectoryEntry. > > > > UNIX has 3 types of timestamps > > > > -The access time is the last time when the content was accessed. > > -The modification time is last time when the content was modified. > > -The change time is the last time when the metadata was modified. > > > > FileSystemDirectoryEntry>>creationTime > > This is wrong because there is no such thing as creation time in UNIX. > > Several linux file systems do support creation time, called birth time, > but my understanding is that there is no standard way to retrieve the > birth time commonly available and cross platform. > > Thanks for the update, I checked and creation time seems not required by POSIX. > > I checked in Linux chmod'ing an empty file and #creationTime displays > the chmod > > "change time". > > Then added content to the file > > > > echo prueba >> test1.txt > > > > And both "creation" and "modification" instance variables were updated. > > > > I couldn't find #accessTime method to get the last timestamp of last > access. > > Linux kernel 4.11 introduced statx(), which adds creation time, but I > don't know if it will be adopted by BSD or MacOS. > > The patches I mentioned earlier and plan for Pharo 7 add support for all > 4 timestamps (creation, change, modification, access). Which fields get > populated depends on the platform. There's a #hasCreationTime flag > which allows you to distinguish between the real creation time and the > change time. > > Maybe #creationTime should answer nil or raise an exception if not supported by underlying file system. It would be nice to has full support for tags. Cheers, HernÃ¡n > Cheers, > Alistair > >

June 20, 2017

Re: Bloated image again. Memory leak?

by Davide Varvello

Thanks for the article Phil and yep I generate many reports from the inspection of a lot of collections Davide philippeback wrote > On Mon, Jun 19, 2017 at 11:52 AM, Davide Varvello via Pharo-users < > pharo-users@.pharo >> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Davide Varvello < > varvello@ > > >> To: > pharo-users@.pharo >> Cc: >> Bcc: >> Date: Mon, 19 Jun 2017 02:52:08 -0700 (PDT) >> Subject: Re: Bloated image again. Memory leak? >> Thank you very much Phil, >> Your code works! The image went from 600MB to 80MB >> > > I suffered from such a thing for a long time, and thanks to ClÃ©ment and > Pavel, we are not having to suffer that bloat anymore :-) > > This article is worth a read for making things fast(er) in some cases (if > you got to 600MB then you were inspecting decently sized collections): > https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > > Phil > -- View this message in context: http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951975.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 20, 2017

Re: Bloated image again. Memory leak?

by Davide Varvello

Fine Davide EstebanLM wrote >> On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users < > pharo-users@.pharo > > wrote: >> >> >> From: Davide Varvello < > varvello@ > <mailto: > varvello@ > >> >> Subject: Re: Bloated image again. Memory leak? >> Date: 19 June 2017 at 11:52:08 GMT+2 >> To: > pharo-users@.pharo > <mailto: > pharo-users@.pharo > > >> >> >> Thank you very much Phil, >> Your code works! The image went from 600MB to 80MB >> >> I'm wondering why there is no bug record about GLMPanePort on >> https://pharo.fogbugz.com/f/search/?sSearchFor=GLMPanePort >> <https://pharo.fogbugz.com/f/search/?sSearchFor=GLMPanePort> nor a >> fix. Nobody >> has this issue, but you and me? I'm puzzled. > > I think because this was a more general bug that *should* be fixed on > Pharo 6. > > cheers! > Esteban > >> >> Anyway >> Thank you very much >> Davide >> >> >> philippeback wrote >>> Check >>> >>> https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e >>> <https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e> >>> >>> Phil >>> >>> On Mon, Jun 19, 2017 at 8:45 AM, Davide Varvello via Pharo-users < >> >>> pharo-users@.pharo >> >>>> wrote: >>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Davide Varvello < >> >>> varvello@ >> >>> > >>>> To: >> >>> pharo-users@.pharo >> >>>> Cc: >>>> Bcc: >>>> Date: Sun, 18 Jun 2017 23:45:32 -0700 (PDT) >>>> Subject: Bloated image again. Memory leak? >>>> Hi guys, >>>> I have this problem (http://forum.world.st/Huge-image-td4876854.html) >>>> now >>>> the image grow about 100MB per week and the suggestions shown on >>>> http://forum.world.st/Huge-image-td4876854.html don't work >>>> >>>> I'm on Pharo 5 on a mac. >>>> >>>> I suspect it is something related to GLMPanePort, see the attached jpg >>>> Can you help me please? >>>> >>>> TIA >>>> Davide >>>> >>>> >>>> <http://forum.world.st/file/n4951861/huge_image2.jpg> >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Bloated- >>>> image-again-Memory-leak-tp4951861.html >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951885.html >> <http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951885.html> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com >> <http://nabble.com/>. -- View this message in context: http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951973.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 20, 2017

Re: [Pharo-users] Bloated image again. Memory leak?

by Esteban Lorenzano

> On 20 Jun 2017, at 08:16, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > What is the more general problem esteban? what *was* the general problem: there was a leak on glamour :) Esteban > > On Mon, Jun 19, 2017 at 12:10 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users >> <pharo-users(a)lists.pharo.org> wrote: >> >> >> From: Davide Varvello <varvello(a)yahoo.com> >> Subject: Re: Bloated image again. Memory leak? >> Date: 19 June 2017 at 11:52:08 GMT+2 >> To: pharo-users(a)lists.pharo.org >> >> >> Thank you very much Phil, >> Your code works! The image went from 600MB to 80MB >> >> I'm wondering why there is no bug record about GLMPanePort on >> https://pharo.fogbugz.com/f/search/?sSearchFor=GLMPanePort nor a fix. Nobody >> has this issue, but you and me? I'm puzzled. >> >> >> I think because this was a more general bug that *should* be fixed on Pharo >> 6. >> >> cheers! >> Esteban >> >> >> Anyway >> Thank you very much >> Davide >> >> >> philippeback wrote >> >> Check >> >> https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e >> >> Phil >> >> On Mon, Jun 19, 2017 at 8:45 AM, Davide Varvello via Pharo-users < >> >> >> pharo-users@.pharo >> >> >> wrote: >> >> >> >> >> ---------- Forwarded message ---------- >> From: Davide Varvello < >> >> >> varvello@ >> >> >> > >> >> To: >> >> >> pharo-users@.pharo >> >> >> Cc: >> Bcc: >> Date: Sun, 18 Jun 2017 23:45:32 -0700 (PDT) >> Subject: Bloated image again. Memory leak? >> Hi guys, >> I have this problem (http://forum.world.st/Huge-image-td4876854.html) >> now >> the image grow about 100MB per week and the suggestions shown on >> http://forum.world.st/Huge-image-td4876854.html don't work >> >> I'm on Pharo 5 on a mac. >> >> I suspect it is something related to GLMPanePort, see the attached jpg >> Can you help me please? >> >> TIA >> Davide >> >> >> <http://forum.world.st/file/n4951861/huge_image2.jpg> >> >> >> >> -- >> View this message in context: http://forum.world.st/Bloated- >> image-again-Memory-leak-tp4951861.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951885.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >

June 20, 2017

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

by Stephane Ducasse

Ahh tx I understand now. I can tell you that I'm eager to do integration with git to avoid to get MC checking all the repo from earth and merging :) Stef On Mon, Jun 19, 2017 at 1:09 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > there was an issue with presumably gitfiletree, that when checking a code against its repo (to commit or show changes), every single repository would be refreshed, which took quite a while (on the order of seconds to tens of seconds, but it was quite annoying as it happened frequently).. so as I don't need the repos unless I am fixing the bug, I removed them... > > I don't use it in Pharo 6 as I haven't experienced the issue there, but I am using Iceberg now, so maybe that is the reason. > > Peter > > > On Sat, Jun 17, 2017 at 03:19:41AM -0700, webwarrior wrote: >> Well, that is the question to the author of original script - Peter Uhnak. >> >> The goal is to avoid contacting server (takes alot of time and blocks the >> image) every time you save a package to a filetree repo. As I understand >> repositories in question are kind of special and are always checked, so >> removing them solves the problem. >> >> I just modified it to work on Pharo6. >> >> >> >> -- >> View this message in context: http://forum.world.st/Saving-to-local-git-and-Loading-all-file-names-from-h… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >

June 20, 2017

Re: [Pharo-users] WrapAthen, World coordinate?

by Stephane Ducasse

:( Hi nicolai I really hope that github support and bootstrap will help for that With the bootstrap we are reloading code so we should reload Athens from the Pharo folder and people will be able to load this code too. For now I would consider that the code in the image is the latest "working" one. Does it make sense? Stef On Mon, Jun 19, 2017 at 8:53 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Done: > > 20166 wrong cliprect on transformed athens canvas > > Although I don't know how we handle fixes for Athens, as the current > repository and in-image version already diverged again. > > > > 2017-06-19 8:15 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi hilaire >> >> Can you add a bug entry in the pharo bug tracker? >> We cannot look at bugs that are not listed there. >> >> Stef >> >> On Sun, Jun 18, 2017 at 4:11 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >> > Only the picture I sent previously, but Nicolas tracked the problem in >> > the clipping default choices: >> > >> > https://bugs.launchpad.net/drgeo/+bug/1698582 >> > >> > Le 18/06/2017 Ã 15:41, Stephane Ducasse a Ã©crit : >> >> Do you have an expression showing the problem? >> > >> > -- >> > Dr. Geo >> > http://drgeo.eu >> > >> > >> >

June 20, 2017

Re: [Pharo-users] Bloated image again. Memory leak?

by Stephane Ducasse

What is the more general problem esteban? On Mon, Jun 19, 2017 at 12:10 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: > > > From: Davide Varvello <varvello(a)yahoo.com> > Subject: Re: Bloated image again. Memory leak? > Date: 19 June 2017 at 11:52:08 GMT+2 > To: pharo-users(a)lists.pharo.org > > > Thank you very much Phil, > Your code works! The image went from 600MB to 80MB > > I'm wondering why there is no bug record about GLMPanePort on > https://pharo.fogbugz.com/f/search/?sSearchFor=GLMPanePort nor a fix. Nobody > has this issue, but you and me? I'm puzzled. > > > I think because this was a more general bug that *should* be fixed on Pharo > 6. > > cheers! > Esteban > > > Anyway > Thank you very much > Davide > > > philippeback wrote > > Check > > https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e > > Phil > > On Mon, Jun 19, 2017 at 8:45 AM, Davide Varvello via Pharo-users < > > > pharo-users@.pharo > > > wrote: > > > > > ---------- Forwarded message ---------- > From: Davide Varvello < > > > varvello@ > > > > > > To: > > > pharo-users@.pharo > > > Cc: > Bcc: > Date: Sun, 18 Jun 2017 23:45:32 -0700 (PDT) > Subject: Bloated image again. Memory leak? > Hi guys, > I have this problem (http://forum.world.st/Huge-image-td4876854.html) > now > the image grow about 100MB per week and the suggestions shown on > http://forum.world.st/Huge-image-td4876854.html don't work > > I'm on Pharo 5 on a mac. > > I suspect it is something related to GLMPanePort, see the attached jpg > Can you help me please? > > TIA > Davide > > > <http://forum.world.st/file/n4951861/huge_image2.jpg> > > > > -- > View this message in context: http://forum.world.st/Bloated- > image-again-Memory-leak-tp4951861.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > > -- > View this message in context: > http://forum.world.st/Bloated-image-again-Memory-leak-tp4951862p4951885.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 20, 2017