June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Teapot session

by phil＠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 <horrido.hobbies(a)gmail.com> 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. > > >

June 19, 2017

Re: [Pharo-users] UUIDGenerator

by 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, phil(a)highoctane.be <mailto:phil@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 <tim(a)testit.works <mailto:tim@testit.works>> 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 <horrido.hobbies(a)gmail.com <mailto:horrido.hobbies@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 <http://forum.world.st/UUIDGenerator-tp4951725p4951731.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/UUIDGenerator- <http://forum.world.st/UUIDGenerator-> >>>> tp4951725p4951743.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/UUIDGenerator-tp4951725p4951844.html <http://forum.world.st/UUIDGenerator-tp4951725p4951844.html> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com <http://nabble.com/>. > >

June 19, 2017

Re: [Pharo-users] Teapot session

by Sven Van Caekenberghe

> On 19 Jun 2017, at 17:11, horrido <horrido.hobbies(a)gmail.com> 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. >

June 19, 2017

Re: [Pharo-users] Teapot session

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

June 19, 2017

Re: [Pharo-users] Teapot session

by Sven Van Caekenberghe

> On 19 Jun 2017, at 15:40, horrido <horrido.hobbies(a)gmail.com> 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.

June 19, 2017

Re: [Pharo-users] Teapot session

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

June 19, 2017

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

by Sven Van Caekenberghe

Thx ! > On 19 Jun 2017, at 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: > > 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 <lewis(a)mail.msen.com> 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 >>>> >>> >

June 19, 2017

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

by 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 <lewis(a)mail.msen.com> 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 > >> > >

June 19, 2017

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

by 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

June 19, 2017

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

by 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-h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 19, 2017