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

[Davide Varvello via Pharo-users]

--- Begin Message ---
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


 



--
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.

--- End Message ---

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

[p...@highoctane.be]

Check

https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e

Phil

On Mon, Jun 19, 2017 at 8:45 AM, Davide Varvello via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-users@lists.pharo.org
> 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
>
>
> 
>
>
>
> --
> 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.
>
>
>
>

Re: [Pharo-users] Finding files in Pharo

[Alistair Grant]

Hi Hernan,

On Sat, Jun 17, 2017 at 11:59:59PM -0300, Hern??n Morales Durand wrote:
> I would like to find files in Pharo like the UNIX find command:
> 
> find . -iname "*.txt" -type f -print
> 
> find . \( -iname "*.txt" -o -iname "*.csv" \) -print
> 
> find . -maxdepth 2 -name "example*"  -type f -print
> 
> find . -type f -atime -7 -size +2M -perm 644 -print
> 
> Do we have some package on top of FileSystem to make complex find searches?

You might also like to look at the FileSystemVisitor class and subclasses.

Currently you can't strictly do a "-type f" test.  The closest at the
moment is "isDirectory" and "isDirectory not" (which is what #isFile is
defined as).

I've got some patches lined up which will allow you to test things like
#isRegular (which matches "-type f"), #isSymlink, etc.  But it will be
a while before they become available as it involves a new VM plugin.

Cheers,
Alistair

Re: [Pharo-users] UUIDGenerator

[Tim Mackinnon]

It is in the Pharo help - however I have noticed that Help doesn’t have a 
convenient search box and the new Welcome screen that launches with Pharo 
possibly should have a shortcut to useful navigational features…. Sounds like 
something I can contributed.

Tim

> On 19 Jun 2017, at 00:39, horrido  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 
> .

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

[Davide Varvello via Pharo-users]

--- Begin Message ---
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.

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
>>
>>
>> ;
>>
>>
>>
>> --
>> 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.

--- End Message ---

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

[Esteban Lorenzano]

> On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users 
>  wrote:
> 
> 
> From: Davide Varvello mailto:varve...@yahoo.com>>
> Subject: Re: Bloated image again. Memory leak?
> Date: 19 June 2017 at 11:52:08 GMT+2
> To: pharo-users@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
>>> 
>>> 
>>> ;
>>> 
>>> 
>>> 
>>> --
>>> 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 
> .

Re: [Pharo-users] UUIDGenerator

[p...@highoctane.be]

That being said, maybe one can do a spotter extension that looks into the
help topics.

I did one with windows (should be in Pharo7).

So one would ho to spotter and put a word followed by #help or #he

Maybe this is in already!
Phil

On Mon, Jun 19, 2017 at 10:43 AM, Tim Mackinnon  wrote:

> It is in the Pharo help - however I have noticed that Help doesn’t have a
> convenient search box and the new Welcome screen that launches with Pharo
> possibly should have a shortcut to useful navigational features…. Sounds
> like something I can contributed.
>
> Tim
>
> On 19 Jun 2017, at 00:39, horrido  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
> .
>
>
>

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

[p...@highoctane.be]

On Mon, Jun 19, 2017 at 11:52 AM, Davide Varvello via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Davide Varvello 
> To: pharo-users@lists.pharo.org
> 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-collector/

Phil




> 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.
>
> 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
> >>
> >>
> >> ;
> >>
> >>
> >>
> >> --
> >> 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.
>
>
>
>

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

[Peter Uhnak]

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-http-pharo5-inbox-tp4897962p4951723.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[Hilaire]

Hi David, Steph,

The fix works fine on P6 64 bits too!

Thanks

Hilaire

Le 19/06/2017 à 08:10, Stephane Ducasse a écrit :
> Thanks David.
> Once hilaire confirms it can you create a bug entry in pharo bug tracker?
> 
> S.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[David T. Lewis]

I opened new issue 20167 for this.

Dave


On Mon, Jun 19, 2017 at 08:10:20AM +0200, Stephane Ducasse wrote:
> Thanks David.
> Once hilaire confirms it can you create a bug entry in pharo bug tracker?
> 
> S.
> 
> On Sun, Jun 18, 2017 at 9:37 PM, David T. Lewis  wrote:
> > Hi Hilaire,
> >
> > I confirmed this on Squeak, and added a new test based on your example.
> >
> > The test is at
> >   
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194766.html,
> >
> > and the fix is
> >   
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194767.html
> >
> > I did not check a Pharo image, but I expect is the same issue for both Pharo
> > and Squeak. The problem is that PNGReadWriter is making 4 byte large 
> > integers,
> > then passing them as parameters to a primitive. On 64-bit Spur images, the
> > large integers need to be normalized to turn them into immediate short 
> > integers
> > prior to calling the primitive.
> >
> > This is a simple change to four methods so you can patch your image locally 
> > to
> > confirm the fix.
> >
> > HTH,
> > Dave
> >
> > On Sun, Jun 18, 2017 at 02:01:08PM +0200, Hilaire wrote:
> >> The code bellow decodes the PNG picture just fine in P3, in P6 it can't!
> >>
> >> I suspect changes in PNGReaderWriter>>nextImage
> >> However the version shows no history of edit :(
> >>
> >> One should add this code below in a test for PNG.
> >>
> >>
> >> PNGReadWriter createAFormFrom: #(137 80 78 71 13 10 26 10 0 0 0 13 73 72
> >> 68 82 0 0 0 48 0 0 0 48 16 6 0 0 0 7 146 37 196 0 0 0 6 98 75 71 68 255
> >> 255 255 255 255 255 9 88 247 220 0 0 0 9 112 72 89 115 0 0 0 72 0 0 0 72
> >> 0 70 201 107 62 0 0 1 153 73 68 65 84 120 218 237 155 73 110 195 48 12
> >> 69 227 162 183 211 9 180 11 130 220 77 39 208 249 210 77 181 8 81 69 19
> >> 39 169 255 109 12 35 137 197 255 105 81 244 144 219 13 0 0 0 0 0 116 16
> >> 66 8 33 188 94 214 113 120 99 214 151 111 238 1 115 206 57 231 235 178
> >> 54 68 10 238 19 112 58 1 189 1 238 158 16 233 25 255 37 117 224 221 141
> >> 215 210 193 158 128 83 140 215 210 181 156 0 26 216 169 139 180 155 210
> >> 218 50 184 124 126 74 34 122 245 204 234 101 207 224 41 221 145 150 14
> >> 49 67 118 77 132 118 220 98 93 208 168 64 107 172 226 18 63 19 91 194
> >> 172 103 132 117 124 106 194 117 132 210 227 215 143 103 109 124 65 173 4
> >> 181 4 173 149 128 254 223 121 49 190 160 190 6 212 4 126 22 94 12 163 91
> >> 173 241 229 112 219 141 188 51 106 184 223 46 139 162 62 3 164 137 49
> >> 198 24 253 117 89 219 241 183 145 181 82 180 94 154 192 47 212 248 247
> >> 253 209 45 152 102 205 120 36 130 137 182 193 159 19 5 22 233 53 158 126
> >> 31 48 209 54 190 181 15 8 189 247 215 71 141 174 25 127 218 243 137 105
> >> 168 17 53 99 164 140 247 154 8 183 119 67 139 177 41 165 148 210 117 209
> >> 125 233 241 181 16 187 18 158 21 254 124 62 30 247 251 186 241 173 113
> >> 122 227 148 70 237 145 100 175 33 210 120 139 207 205 237 232 255 22 71
> >> 129 45 16 60 3 158 163 123 6 140 214 74 239 198 207 198 201 189 102 12
> >> 151 32 26 128 155 23 150 22 105 189 96 38 181 88 31 211 206 113 163 165
> >> 151 109 17 182 110 231 118 213 193 222 5 237 154 8 171 184 217 254 31
> >> 176 123 9 114 255 146 177 187 128 224 3 0 0 0 0 192 198 252 0 102 116 72
> >> 96 211 171 62 8 0 0 0 0 73 69 78 68 174 66 96 130) asByteArray
> >>
> >>
> >>
> >> --
> >> Dr. Geo
> >> http://drgeo.eu
> >>
> >

Re: [Pharo-users] Teapot session

[horrido]

I've added an attribute to the session called #user...

req session attributeAt: #user ifAbsentPut: user

This is used to *determine if I'm logged in*. On logout, I would like to
*remove* this attribute, but I can't figure out how to do it. Suggestion?



Sven Van Caekenberghe-2 wrote
> If you are talking about ZnServerSessions, the ones returned from
> ZnRequest>>#session, then the answer is that they are eligible for
> expiration and cleanup after 1 hour (see ZnServerSession>>#isValid).
> Cleanup happens inZnSingleThreadedServer>>#periodTasks. Right now, the
> expiration time is a fixed constant.
> 
>> On 19 Jun 2017, at 08:08, Stephane Ducasse <

> stepharo.self@

> > wrote:
>> 
>> Teapot is a layer on zinc so you may check the Zinc chapters (I do not
>> know if this is there).
>> 
>> 
>> On Mon, Jun 19, 2017 at 1:42 AM, horrido <

> horrido.hobbies@

> > wrote:
>>> Does Teapot's (ZnRequest's?) session ever expire? What is the expiry
>>> period?
>>> 
>>> I can't find where it's specified or configured.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://forum.world.st/Teapot-session-tp4951845.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> 
>>





--
View this message in context: 
http://forum.world.st/Teapot-session-tp4951845p4951905.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Teapot session

[Sven Van Caekenberghe]

> On 19 Jun 2017, at 15:40, horrido  wrote:
> 
> I've added an attribute to the session called #user...
> 
> req session attributeAt: #user ifAbsentPut: user
> 
> This is used to *determine if I'm logged in*. On logout, I would like to
> *remove* this attribute, but I can't figure out how to do it. Suggestion?

req session removeAttribute: #user

> Sven Van Caekenberghe-2 wrote
>> If you are talking about ZnServerSessions, the ones returned from
>> ZnRequest>>#session, then the answer is that they are eligible for
>> expiration and cleanup after 1 hour (see ZnServerSession>>#isValid).
>> Cleanup happens inZnSingleThreadedServer>>#periodTasks. Right now, the
>> expiration time is a fixed constant.
>> 
>>> On 19 Jun 2017, at 08:08, Stephane Ducasse <
> 
>> stepharo.self@
> 
>> > wrote:
>>> 
>>> Teapot is a layer on zinc so you may check the Zinc chapters (I do not
>>> know if this is there).
>>> 
>>> 
>>> On Mon, Jun 19, 2017 at 1:42 AM, horrido <
> 
>> horrido.hobbies@
> 
>> > wrote:
 Does Teapot's (ZnRequest's?) session ever expire? What is the expiry
 period?
 
 I can't find where it's specified or configured.
 
 
 
 
 --
 View this message in context:
 http://forum.world.st/Teapot-session-tp4951845.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
 
>>> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Teapot-session-tp4951845p4951905.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Teapot session

[horrido]

Interesting. Auto-complete doesn't show #removeAttribute: as an option.

Another question: After I've logged out, I can still click on Backpage in
the browser to get to a page that should no longer be authorized. Is there a
way to prevent this? Is there a way to invalidate the page?



Sven Van Caekenberghe-2 wrote
>> On 19 Jun 2017, at 15:40, horrido <

> horrido.hobbies@

> > wrote:
>> 
>> I've added an attribute to the session called #user...
>> 
>> req session attributeAt: #user ifAbsentPut: user
>> 
>> This is used to *determine if I'm logged in*. On logout, I would like to
>> *remove* this attribute, but I can't figure out how to do it. Suggestion?
> 
> req session removeAttribute: #user
> 
>> Sven Van Caekenberghe-2 wrote
>>> If you are talking about ZnServerSessions, the ones returned from
>>> ZnRequest>>#session, then the answer is that they are eligible for
>>> expiration and cleanup after 1 hour (see ZnServerSession>>#isValid).
>>> Cleanup happens inZnSingleThreadedServer>>#periodTasks. Right now, the
>>> expiration time is a fixed constant.
>>> 
 On 19 Jun 2017, at 08:08, Stephane Ducasse <
>> 
>>> stepharo.self@
>> 
>>> > wrote:
 
 Teapot is a layer on zinc so you may check the Zinc chapters (I do not
 know if this is there).
 
 
 On Mon, Jun 19, 2017 at 1:42 AM, horrido <
>> 
>>> horrido.hobbies@
>> 
>>> > wrote:
> Does Teapot's (ZnRequest's?) session ever expire? What is the expiry
> period?
> 
> I can't find where it's specified or configured.
> 
> 
> 
> 
> --
> View this message in context:
> http://forum.world.st/Teapot-session-tp4951845.html
> Sent from the Pharo Smalltalk Users mailing list archive at
> Nabble.com.
> 
 
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://forum.world.st/Teapot-session-tp4951845p4951905.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.





--
View this message in context: 
http://forum.world.st/Teapot-session-tp4951845p4951908.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Teapot session

[Sven Van Caekenberghe]

> On 19 Jun 2017, at 17:11, horrido  wrote:
> 
> Interesting. Auto-complete doesn't show #removeAttribute: as an option.
> 
> Another question: After I've logged out, I can still click on Backpage in
> the browser to get to a page that should no longer be authorized. Is there a
> way to prevent this? Is there a way to invalidate the page?

It is in general impossible to prevent the user from going backwards in its 
browser. Still, it should not make any difference: the session remains 
de-autherized, so the user can not do any further requests, all the (protected) 
links s/he clicks are invalid.

> Sven Van Caekenberghe-2 wrote
>>> On 19 Jun 2017, at 15:40, horrido <
> 
>> horrido.hobbies@
> 
>> > wrote:
>>> 
>>> I've added an attribute to the session called #user...
>>> 
>>> req session attributeAt: #user ifAbsentPut: user
>>> 
>>> This is used to *determine if I'm logged in*. On logout, I would like to
>>> *remove* this attribute, but I can't figure out how to do it. Suggestion?
>> 
>> req session removeAttribute: #user
>> 
>>> Sven Van Caekenberghe-2 wrote
 If you are talking about ZnServerSessions, the ones returned from
 ZnRequest>>#session, then the answer is that they are eligible for
 expiration and cleanup after 1 hour (see ZnServerSession>>#isValid).
 Cleanup happens inZnSingleThreadedServer>>#periodTasks. Right now, the
 expiration time is a fixed constant.
 
> On 19 Jun 2017, at 08:08, Stephane Ducasse <
>>> 
 stepharo.self@
>>> 
 > wrote:
> 
> Teapot is a layer on zinc so you may check the Zinc chapters (I do not
> know if this is there).
> 
> 
> On Mon, Jun 19, 2017 at 1:42 AM, horrido <
>>> 
 horrido.hobbies@
>>> 
 > wrote:
>> Does Teapot's (ZnRequest's?) session ever expire? What is the expiry
>> period?
>> 
>> I can't find where it's specified or configured.
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://forum.world.st/Teapot-session-tp4951845.html
>> Sent from the Pharo Smalltalk Users mailing list archive at
>> Nabble.com.
>> 
> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://forum.world.st/Teapot-session-tp4951845p4951905.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Teapot-session-tp4951845p4951908.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] UUIDGenerator

[Tim Mackinnon]

Damnit your right…. #help keyboard gives you the business… nice

I think the prompt to use Spotter should be in the welcome text though, as its 
a bit hidden - maybe is should be in the “Explore” section.

Tim


> On 19 Jun 2017, at 11:30, p...@highoctane.be  
> wrote:
> 
> That being said, maybe one can do a spotter extension that looks into the 
> help topics. 
> 
> I did one with windows (should be in Pharo7).
> 
> So one would ho to spotter and put a word followed by #help or #he
> 
> Maybe this is in already!
> Phil
> 
> On Mon, Jun 19, 2017 at 10:43 AM, Tim Mackinnon  > wrote:
> It is in the Pharo help - however I have noticed that Help doesn’t have a 
> convenient search box and the new Welcome screen that launches with Pharo 
> possibly should have a shortcut to useful navigational features…. Sounds like 
> something I can contributed.
> 
> Tim
> 
>> On 19 Jun 2017, at 00:39, horrido > > 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 
>> .
> 
> 

Re: [Pharo-users] Teapot session

[p...@highoctane.be]

Try Ctl-q or Cmd-q after having typed a few chars. Continue until you get a
match.

Works in 6.0

Phil

On Mon, Jun 19, 2017 at 5:11 PM, horrido  wrote:

> Interesting. Auto-complete doesn't show #removeAttribute: as an option.
>
> Another question: After I've logged out, I can still click on Backpage in
> the browser to get to a page that should no longer be authorized. Is there
> a
> way to prevent this? Is there a way to invalidate the page?
>
>
>
> Sven Van Caekenberghe-2 wrote
> >> On 19 Jun 2017, at 15:40, horrido <
>
> > horrido.hobbies@
>
> > > wrote:
> >>
> >> I've added an attribute to the session called #user...
> >>
> >> req session attributeAt: #user ifAbsentPut: user
> >>
> >> This is used to *determine if I'm logged in*. On logout, I would like to
> >> *remove* this attribute, but I can't figure out how to do it.
> Suggestion?
> >
> > req session removeAttribute: #user
> >
> >> Sven Van Caekenberghe-2 wrote
> >>> If you are talking about ZnServerSessions, the ones returned from
> >>> ZnRequest>>#session, then the answer is that they are eligible for
> >>> expiration and cleanup after 1 hour (see ZnServerSession>>#isValid).
> >>> Cleanup happens inZnSingleThreadedServer>>#periodTasks. Right now, the
> >>> expiration time is a fixed constant.
> >>>
>  On 19 Jun 2017, at 08:08, Stephane Ducasse <
> >>
> >>> stepharo.self@
> >>
> >>> > wrote:
> 
>  Teapot is a layer on zinc so you may check the Zinc chapters (I do not
>  know if this is there).
> 
> 
>  On Mon, Jun 19, 2017 at 1:42 AM, horrido <
> >>
> >>> horrido.hobbies@
> >>
> >>> > wrote:
> > Does Teapot's (ZnRequest's?) session ever expire? What is the expiry
> > period?
> >
> > I can't find where it's specified or configured.
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://forum.world.st/Teapot-session-tp4951845.html
> > Sent from the Pharo Smalltalk Users mailing list archive at
> > Nabble.com.
> >
> 
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> http://forum.world.st/Teapot-session-tp4951845p4951905.html
> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Teapot-
> session-tp4951845p4951908.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Re: [Pharo-users] UUIDGenerator

[p...@highoctane.be]

Spotter rulez :-)

On Mon, Jun 19, 2017 at 6:02 PM, Tim Mackinnon  wrote:

> Damnit your right…. #help keyboard gives you the business… nice
>
> I think the prompt to use Spotter should be in the welcome text though, as
> its a bit hidden - maybe is should be in the “Explore” section.
>
> Tim
>
>
> On 19 Jun 2017, at 11:30, p...@highoctane.be wrote:
>
> That being said, maybe one can do a spotter extension that looks into the
> help topics.
>
> I did one with windows (should be in Pharo7).
>
> So one would ho to spotter and put a word followed by #help or #he
>
> Maybe this is in already!
> Phil
>
> On Mon, Jun 19, 2017 at 10:43 AM, Tim Mackinnon  wrote:
>
>> It is in the Pharo help - however I have noticed that Help doesn’t have a
>> convenient search box and the new Welcome screen that launches with Pharo
>> possibly should have a shortcut to useful navigational features…. Sounds
>> like something I can contributed.
>>
>> Tim
>>
>> On 19 Jun 2017, at 00:39, horrido  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
>> .
>>
>>
>>
>
>

Re: [Pharo-users] Finding files in Pharo

[Hernán Morales Durand]

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.

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.


Cheers,

Hernán


2017-06-18 10:43 GMT-03:00 Stephane Ducasse :

> I would love that too :).
> Can you tell us what is missing from the file properties?
>
>
>
> On Sun, Jun 18, 2017 at 4:59 AM, Hernán Morales Durand
>  wrote:
> > I would like to find files in Pharo like the UNIX find command:
> >
> > find . -iname "*.txt" -type f -print
> >
> > find . \( -iname "*.txt" -o -iname "*.csv" \) -print
> >
> > find . -maxdepth 2 -name "example*"  -type f -print
> >
> > find . -type f -atime -7 -size +2M -perm 644 -print
> >
> > Do we have some package on top of FileSystem to make complex find
> searches?
> >
> > Hernán
> >
>
>

Re: [Pharo-users] Anonymous classes performances

[Ben Coman]

@all,  Is there some way to disable garbage collection during such
benchmarks?

cheers -ben


On Sun, Jun 18, 2017 at 3:51 AM, Steven Costiou 
wrote:

> I spent my day testing and comparing execution speed between classes and
> anonymous subclasses when i tried to compare two sets of values between
> pharo classes: they also differ.
>
> In fact it seems that every instruction has a different execution speed if
> we run it enough times. So it seems impossible to precisely compare
> execution time between anon classes and pharo classes, at least i don't
> know how to do it. I computed confidence intervals of various measures, the
> differences in execution time that exist between classes and anonymous
> classes can be between -2% to + 9%. But comparing sets of speed between
> pharo classes, i also have similar intervals (but smaller, from -2% speed
> to +5% speed).
>
>
>
> So maybe they have similar performances, at least sometimes they do and
> sometimes one is slightly faster than the other, but in the end it is not
> possible to tell. But maybe i'm looking for something which does not even
> exist, maybe anonymous classes are designed to be as fast as regular
> classes ? Or maybe it is common to have such variability when benchmarking
> code ?
>
>
>
> Does it exist any instruction in pharo with a constant execution time ?
> (or it could be possible with one million years to compute enough speed
> tests and do an accurate mean...)
>
>
>
> Steven.
>
>
>
> Le 2017-06-16 18:14, Steven Costiou a écrit :
>
> You can find the code below. I just change the call to m by m1 to test the
> two methods.
>
> I started again in a fresh pharo 6 image and now the results seem all
> similar for the following code. I will do all my tests again to see if it
> was my fault but it takes a lot of time (2 hours for each full test).
>
> What sould be the expected results ? Should an instance of an anonymous
> class be as fast as a regular instance when calling the same code, being
> defined in the anon class or its super class ?
>
>
>
> A implements m ^100 printString and B subclass of A implements m1 ^100
> printString
>
> a := B new.
>
>
> class := A newAnonymousSubclass
> addSlot: (InstanceVariableSlot named: #y); compile: 'm1
> ^100 printString'; yourself.
> c := A new becomeForward: class new.
>
> res := Dictionary new.
> col1 := OrderedCollection new.
> col2 := OrderedCollection new.
>
>
> 1 timesRepeat: [
> Smalltalk garbageCollect .
> col1 add: [100 timesRepeat: [ a m ]] timeToRun].
>
>
> 1 timesRepeat: [
> Smalltalk garbageCollect .
> col2 add: [100 timesRepeat: [ c m ]] timeToRun].
>
>
> res at: 'a' put: col1.
> res at: 'c' put: col2.
> res inspect
>
>

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[Ben Coman]

On Mon, Jun 19, 2017 at 8:00 PM, David T. Lewis  wrote:

> 20167


Thanks Dave.   I've cherry-picked those into an integration slice, but I
don't have 64-bit to test on.
@Hilaire, could you test the slice?

cheers -ben

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[Stephane Ducasse]

Thx guys!
We will tag it for a port back to Pharo60.

On Tue, Jun 20, 2017 at 5:05 AM, Ben Coman  wrote:
>
> On Mon, Jun 19, 2017 at 8:00 PM, David T. Lewis  wrote:
>>
>> 20167
>
>
> Thanks Dave.   I've cherry-picked those into an integration slice, but I
> don't have 64-bit to test on.
> @Hilaire, could you test the slice?
>
> cheers -ben

Re: [Pharo-users] Finding files in Pharo

[Alistair Grant]

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.


> 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.

Cheers,
Alistair

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

[Stephane Ducasse]

What is the more general problem esteban?

On Mon, Jun 19, 2017 at 12:10 PM, Esteban Lorenzano  wrote:
>
> On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users
>  wrote:
>
>
> From: Davide Varvello 
> Subject: Re: Bloated image again. Memory leak?
> Date: 19 June 2017 at 11:52:08 GMT+2
> To: pharo-users@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
>
>
> ;
>
>
>
> --
> 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.
>
>

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

[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  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 :
>>
>> 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  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
>> >
>> >
>>
>

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

[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  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-http-pharo5-inbox-tp4897962p4951723.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>

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

[Esteban Lorenzano]

> On 20 Jun 2017, at 08:16, Stephane Ducasse  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  
> wrote:
>> 
>> On 19 Jun 2017, at 11:52, Davide Varvello via Pharo-users
>>  wrote:
>> 
>> 
>> From: Davide Varvello 
>> Subject: Re: Bloated image again. Memory leak?
>> Date: 19 June 2017 at 11:52:08 GMT+2
>> To: pharo-users@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
>> 
>> 
>> ;
>> 
>> 
>> 
>> --
>> 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.
>> 
>> 
>