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

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

by 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 <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 19, 2017

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

by Stephane Ducasse

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] Teapot session

by Stephane Ducasse

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(a)gmail.com> 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. >

June 19, 2017

GT questions

by Torsten Bergmann

Hi, do we have an example on Glamorous Toolkit on 1. how to have a splitter between a pane (for instance to change size for left and right pane on a #dashboard) 2. how to have vertical tabs in a #tabulator 3. on how to use D&D from GT from a list or tree to the world? Thanks T.

June 19, 2017

Teapot session

by horrido

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.

June 18, 2017

Re: [Pharo-users] UUIDGenerator

by horrido

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 18, 2017

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

by David T. Lewis

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 18, 2017

Re: [Pharo-users] Autoformatting in SystemBrowser

by Marc Hanisch

Hi Stephane, Yes it seems to be an issue with the sources file. Maybe my workflow is wrong? When I want to store an image somewhere else, I always left+click and select save as... to save my image. As far as I understand Pharo, it then saves the image and a changes file in the selected directory. The sources file should stay in the Pharo distribution folder, under the share directory, shouldn't it? The sources file is present in my share folder, I don't know why Pharo looks into pharo6.0-64/bin/lib/pharo/5.0- 201705310241/ (that's the path from the error message). ...BTW I'm wondering why the mailing list sends my mails as .eml attachments? Did you received my previous mail? Best regards, Marc Am 18. Juni 2017, um 15:50, schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: I used it daily and it does not come from the formatter. Nicolai suggestion looks a path to investigate because it may be that the code is lost and that the formatter displays text from the bytecode. stef On Sat, Jun 17, 2017 at 10:56 AM, Marc Hanisch via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Marc Hanisch <marc.hanisch(a)googlemail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Sat, 17 Jun 2017 10:56:35 +0200 > Subject: Autoformatting in SystemBrowser > Hello, > > since Pharo6 my method comments in the SystemBrowser gets automatically removed. My arguments get also removed, so when I type: > > SomeClass >> name: aString > "sets the name instance variable" > name := aString > > it gets corrected to: > > SomeClass >> name: arg1 > name := arg1 > > How can I configure this behaviour? I could not find the related settings... :-/ > > Thanks, > Marc >

June 18, 2017

Re: [Pharo-users] How to access path elements of a path

by Stephane Ducasse

Hi alistair Thanks alistair. It looks to me that there is something missing because the printOn: is producing this. Relying on DiskStore current stringFromPath: looks ugly to me. https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing So I propose to add Path >> printPathOn: aStream delimiter: aCharacter "Print the path elements of the receiver, without the 'Path *' part" "String streamContents: [ :str| ((FileSystem workingDirectory / 'book-result' / 'W01-Welcome') relativeToReference: FileSystem workingDirectory) printPathOn: str] >>> 'book-result/W01-Welcome'" (1 to: self size) do: [:index | aStream nextPutAll: (self at: index)] separatedBy: [aStream nextPut: aCharacter] printPathOn: aStream "Print the path elements of the receiver, without the 'Path *' part" "String streamContents: [ :str| ((FileSystem workingDirectory / 'book-result' / 'W01-Welcome') relativeToReference: FileSystem workingDirectory) printPathOn: str] >>> 'book-result/W01-Welcome'" self printPathOn: aStream delimiter: self delimiter pathString "Return a string containing the path elements of the receiver, without the 'Path *' part" " ((FileSystem workingDirectory / 'book-result' / 'W01-Welcome') relativeToReference: FileSystem workingDirectory) pathString >>> 'book-result/W01-Welcome'" ^ String streamContents: [ :str| self printPathOn: str delimiter: self delimiter ] tell me what you think? On Sun, Jun 18, 2017 at 6:05 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Sun, Jun 18, 2017 at 05:54:08PM +0200, Stephane Ducasse wrote: >> Hi guys >> >> (FileSystem workingDirectory / 'book-result' / 'W01-Welcome') >> relativeToReference: FileSystem workingDirectory >> >>> Path * 'book-result' / 'W01-Welcome' >> >> And I would like to get 'book-result/W01-Welcome' >> >> I tried all kind of combination and the lack of comments (Yes I know I >> added the ones there >> is not helping). >> >> Stef > > DiskStore current stringFromPath: > ((FileSystem workingDirectory / 'book-result' / 'W01-Welcome') > relativeToReference: FileSystem workingDirectory) > > will return the string you want. > > But I would argue that Path>>fullName is incorrectly implemented and > should actually be: > > fullName > "Answer the string representation of the receiver" > > ^self delimiter join: self segments > > > Cheers, > Alistair > >

June 18, 2017

Re: [Pharo-users] How to access path elements of a path

by Alistair Grant

Hi Stef, On Sun, Jun 18, 2017 at 05:54:08PM +0200, Stephane Ducasse wrote: > Hi guys > > (FileSystem workingDirectory / 'book-result' / 'W01-Welcome') > relativeToReference: FileSystem workingDirectory > >>> Path * 'book-result' / 'W01-Welcome' > > And I would like to get 'book-result/W01-Welcome' > > I tried all kind of combination and the lack of comments (Yes I know I > added the ones there > is not helping). > > Stef DiskStore current stringFromPath: ((FileSystem workingDirectory / 'book-result' / 'W01-Welcome') relativeToReference: FileSystem workingDirectory) will return the string you want. But I would argue that Path>>fullName is incorrectly implemented and should actually be: fullName "Answer the string representation of the receiver" ^self delimiter join: self segments Cheers, Alistair

June 18, 2017