May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] MouseWheel events

by Matthieu Lacaton

Okay, thank you for your answer, but there is one thing I am not sure I understand : Let's say for example thant I want to create a rectangle on the screen and be able to move it up and down by pressing CTRL + up / down arrow and be able to rotate it with the mouse wheel. Does this mean that on Linux I just can't ? And does this mean that if I create an application able to react to mouse wheel, I need to code it differently for Windows and for Linux ? Matthieu 2015-05-06 23:55 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Matthieu Lacaton wrote > > Shouldn't I get a MouseWheel event when i use the wheel and a keystroke > > when I use CTRL + Arrow ? > > Yes! But the hack that you discovered is what we have :) It's done well for > us given it's simplicity. But it's far from ideal. For instance, IIRC the > delta is fixed, so scrolling a lot sends a lot of tiny scrolls instead of > more appropriately-sized ones. The keystroke-equivalence differences I > think > are due to the underlying platform - the meta key for Mac is CMD, so that > is > what's used. I extended the hack recently to get horizontal scrolling, but > it's only implemented for the Mac VM (there is not even corresponding code > in the image yet, pending Windows/Linux implementation). If you trap the > events, you can see that now it's simulating > cmd+alt+ctrl+shift+[up/down/left/right]. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/MouseWheel-events-tp4824839p4824929.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 10, 2015

Re: [Pharo-users] [ANN] Teapot 0.91

by olivier auverlot

very interesting :-) 2015-05-09 21:13 GMT+02:00 Attila Magyar <m.magyar3(a)gmail.com>: > Hello, > > Teapot 0.91 released today. > > Teapot is micro web framework that focuses on simplicity and ease of use. > > Here's a summary of changes: > - Routes and before/after filters may include conditions (see the example > below) > - Routes can be defined with /any:/ that serves as a wildcard matching any > http method > - Added /charSet:/ accessor to TeaResponse > > E.g. > > Teapot on > GET: 'test' -> result; when: [:req | req accept = 'application/json']; > start. > > More information: > > http://smalltalkhub.com/#!/~zeroflag/Teapot > > > > -- > View this message in context: > http://forum.world.st/ANN-Teapot-0-91-tp4825485.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 10, 2015

Re: [Pharo-users] protobufs for Pharo

by Sven Van Caekenberghe

It would be a nice and welcome addition ! > On 10 May 2015, at 00:39, Benjamin Pollack <benjamin(a)bitquabit.com> wrote: > > Hey all, > > Has anyone implemented protobufs for Pharo yet? Iâve not managed to find any examples, so I assume the answer is ânoâ, but I thought Iâd check here before rolling up my sleeves and writing one myself. (My specific target here is to write a RethinkDB driver, so if someone has magically also done *that*, please let me know, too.) > > Thanks, > --Benjamin

May 10, 2015

protobufs for Pharo

by Benjamin Pollack

Hey all, Has anyone implemented protobufs for Pharo yet? Iâve not managed to find any examples, so I assume the answer is ânoâ, but I thought Iâd check here before rolling up my sleeves and writing one myself. (My specific target here is to write a RethinkDB driver, so if someone has magically also done *that*, please let me know, too.) Thanks, --Benjamin

May 9, 2015

Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1)

by Sven Van Caekenberghe

Hi Peter, > On 09 May 2015, at 19:00, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > Thanks for your considered response to my midnight thoughts. I now see the importance of distinguishing the html side (Soup in my work) from the http side (Zinc). I looked at your specimen byte arrays in a Pharo playground, which I am still learning to use; I hadn't seen that proverb in German, but I see the point you are making. Haha, good ! > Now that my immediate problem is solved, I am not sure whether it is necessary to take up your time any more with it. It depends how many servers do not say what encoding they use, how many sites use encodings other than UTF-8 and how big is the intersection of those sets. If my problem was a one-off, there is no need to go any further. It happens, but not too often (anymore). > However, there is one general point I would like to make. The debugger is a very good tool for programmers investigating their own code, but it is a very unfriendly place for a user dumped in the middle of someone else's code; yesterday I learned more than I ever wished to about the innards of UTF-8 decoding, before realising it was all irrelevant. If you do think it worth modifying the handling of this case, I would suggest replacing the call to the debugger with a dialog box of some sort, perhaps with debug as an option for the enthusiast, but perhaps also with an option to restart with an alternative encoding. I understand your idea, but showing dialogs from system code is a no go, all that we can do is throw better or more specific exceptions, it is up to the code invoking things (your code/application) to handle those. > If I can, I would like to ask a supplementary question - I am deeply ignorant but eager to learn. As I mentioned, I tried to get round the problem by downloading the page source to a local file and reading from there into Soup, but this also involved the Zinc decoder and so failed. I tried to see how to get round this, using what I now know about the encoding, and came up with the following: > > binaryStream := (FileStream readOnlyFileNamed: 'display.html') binary. > charStream := ZnCharacterReadStream on: binaryStream encoding: ZnByteEncoder iso88591. > hbSoup := Soup fromString: charStream contents. Yes, that is perfect (did you see http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ ?) I would write 'display.html' asFileReference binaryReadStreamDo: [ :in | Soup fromString: (ZnCharacterReadStream on: in encoding: ZnByteEncoder iso88591) upToEnd ]. or even 'display.html' asFileReference binaryReadStreamDo: [ :in | Soup fromString: (ZnByteEncoder iso88591 decodeBytes: in upToEnd) ]. It seems Soup does not accept streams, only strings. > This worked, so in that sense it is OK, but I wonder if there is a neater way of doing it. More importantly, I found that Soup has its own decoder, so I can skip the second line and replace the third by: > > hbSoup := Soup fromString: binaryStream contents asString. > > At one stage I found myself looking at a debugger on this process (I know - this contradicts what I said above!), because I had not realised that 'asString' was needed. It looked as though Soup was trying three candidate encodings, which it labelled 'latin1', 'utf-8' and 'cp1252', to find which one would work. It showed the one it had 'sniffed' as most likely being 'latin1', which I think is the same as ISO-8859-1, so it was trying that first. Yes Latin1, cp1252 and ISO88591 are equivalent for most purposes. BTW, #asString is also more or less the same (the difference is that there is a 'hole' in the encoding). > > Given this, my question is whether Zinc would allow me to read from a web URL as a binary stream, which I could then feed into the Soup decoder in the same way. If I can, I would use this as my standard procedure; I expect to be visiting a lot of sites, and it would be handy to be able to ignore the encoding issue and hope that Soup can sort it out. Downloading binary to a file goes like this: ZnClient new url: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…'; downloadTo: 'display.html'. If you would want the bytes in memory, you could do: | client bytes | (client := ZnClient new) streaming: true; get: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…'. bytes := client entity contents. client close. bytes. > Finally, a general comment. Both this query and the one I posed earlier this week, answered by Vincent Blondeau, showed that Pharo users can come to this site and expect quick, friendly and expert help. I am retired and can devote all the time I want to this, but you people must have day jobs as well! I am really very grateful. To get anywhere, we have to help each other. Sven > Best wishes > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe > Sent: 09 May 2015 07:51 > To: Any question about pharo is welcome > Subject: Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1) > > >> On 09 May 2015, at 02:18, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >> Sven >> >> Many thanks for the quick response. I always like to try to solve problems myself before appealing for help, so I had worked out what was wrong, but did not know how to tell Zinc to use a specific coding. I had tried by reading through your very full note on Zinc, but did not find the trick you describe - which works perfectly, of course. > > Good, yes this is a more recent thing. > >> It seems unfortunate that Zinc does not use the coding specified in the html head. Evidently browsers like Firefox must do it, since the page displays correctly. If it cannot be done, I think it would be helpful to reconsider the error message produced when the user is dumped out, because in this context it is misleading. I spent some time tracing debugger output, trying to work out what was wrong with the UTF-8, before I spotted that one of the bytes was displayed in character form as $Ã¶, and began to suspect it might be a different coding; I finally confirmed this by reading the page source in Firefox. > > Zn deals with HTTP, not with HTML, these are totally different things, a browser obviously does both. But even then there is no easy way to do this, apart from trying. Consider these two byte arrays: > > #[85 84 70 56 58 32 68 101 114 32 87 101 103 32 122 117 114 32 72 195 182 108 108 101 32 105 115 116 32 109 105 116 32 103 117 116 101 110 32 86 111 114 115 195 164 116 122 101 110 32 103 101 112 102 108 97 115 116 101 114 116 46] > > #[73 83 79 56 56 53 57 49 58 32 68 101 114 32 87 101 103 32 122 117 114 32 72 246 108 108 101 32 105 115 116 32 109 105 116 32 103 117 116 101 110 32 86 111 114 115 228 116 122 101 110 32 103 101 112 102 108 97 115 116 101 114 116 46] > > In them it says how you should decode them! > > The GT tools make this challenge easy because there is a tab that tries both encodings, but in general this is hard to solve (efficiently). > > But since Zn does not do HTML, it will never be added at that level. > > I will think about the error, it might indeed be useful to tell the user that a default encoding was chosen. > >> Thanks again for your help. > > You're welcome. > >> Peter Kenny >> >> -----Original Message----- >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >> Sent: 08 May 2015 20:04 >> To: Any question about pharo is welcome >> Subject: Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1) >> >> Peter, >> >> Thanks for the URL, it makes it much easier to help you. >> >> The answer is easy: the server is incorrect, it serves a specific encoding without saying so. >> >> Consider: >> >> (ZnClient new >> head: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…'; >> response) contentType. >> >> => 'text/html' >> >> If no charset/encoding is specified, the modern default is UTF-8, so Zn tries that but fails. >> >> You can change the default for unspecified encoding as follows: >> >> ZnDefaultCharacterEncoder >> value: ZnByteEncoder iso88591 >> during: [ >> ZnClient new >> get: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…' ]. >> >> The server should have used the following mime type to avoid the confusion: >> >> ZnMimeType textHtml charSet: #iso88591 >> >> => 'text/html;charset=iso88591' >> >> HTH, >> >> Sven >> >> PS: the encoding inside the document cannot be used because (1) no interpretation inside documents is done and (2) at that point it is too late, the contents is already converted from bytes to characters >> >>> On 08 May 2015, at 18:51, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >>> >>> Hello >>> >>> I have been trying to use Soup class>> fromUrl: to access the contents of a web page. It halts with a message from Zinc about malformed UTF-8. The page displays perfectly in Firefox, so I copied the page source from there to a local file and tried to read it from there. Again a message from Zinc: 'Invalid utf8 input detected'. Itâs strange, because the page is not in UTF-8. The head contains: <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">. I have tried to find how to specify the character set in reading files with Zinc, but without success.* >>> >>> If itâs relevant, I am using Pharo4.0 Latest update: #40613, downloaded two days ago. The address of the web page is: http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…. Other pages from the same source are loaded and analysed with no problem. Processing this page seems to go off course as soon as it encounters the character code 246, which is a correct o-umlaut in ISO-8859-1. >>> >>> Any advice gratefully received. >>> >>> Peter Kenny >>> >>> *I would be happy with advice to RTFM, if someone would point out the relevant bit of the FM. >> >> >> > > >

May 9, 2015

[ANN] Teapot 0.91

by Attila Magyar

Hello, Teapot 0.91 released today. Teapot is micro web framework that focuses on simplicity and ease of use. Here's a summary of changes: - Routes and before/after filters may include conditions (see the example below) - Routes can be defined with /any:/ that serves as a wildcard matching any http method - Added /charSet:/ accessor to TeaResponse E.g. Teapot on GET: 'test' -> result; when: [:req | req accept = 'application/json']; start. More information: http://smalltalkhub.com/#!/~zeroflag/Teapot -- View this message in context: http://forum.world.st/ANN-Teapot-0-91-tp4825485.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 9, 2015

Re: [Pharo-users] initializeWith* and constructors

by stepharo

But remember that it was before new invoke initialized was introduced. We introduced back in squeak because it helps newcomers: they do not have to understand metaclass the first day. Stef Le 4/5/15 00:40, Carlo a Ã©crit : > Hi > > Kent Beck came up with some useful idioms in his book Smalltalk Best > Practice Patterns. > One of them was the 'Creation Parameter Method' which is basically the > "set" based initialisation method (which Ben mentioned below). This > idiom used in conjunction with the "Complete Creation Method" I > believe helps communicate "how can I create a valid instance?" to > users of your objects. > > Cheers > Carlo > > > On 02 May 2015, at 4:52 PM, Ben Coman <btc(a)openInWorld.com > <mailto:btc@openInWorld.com>> wrote: > > There are other conventions like: > > * set... > * Delay class >> forMilliseconds: aNumber > ^ self new setDelay: aNumber forSemaphore: Semaphore new > > * initializeFor... > * DynamicMessageImplementor class>>#for:in: > ^ self new initializeFor: aMessage in: aClass > > * from:to:... > * Bezier2Segment class>>#from:to:via: > ^self new from: startPoint to: endPoint via: viaPoint > > I dug a bit to produce this script so you can view more yourself... > > protocols := (Protocol allInstances select: [ :p | p name = > 'instance creation' ]) flatCollect: [ :p | p methods ]. > methods := protocols select: [ :m | (m occurrencesOf: $:) > 1 ]. > implementors := methods flatCollect: [ :m | m implementors ]. > constructorExamples := implementors select: [ :i | (i sourceCode > includesAll: 'new') or: [ i sourceCode includesAll: 'basicNew' ] ]. > > cheers -ben > > > On Sat, May 2, 2015 at 9:02 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > It seems to me that Smalltalkers are not very fond of constructors > and I can't comprehend why. > > If for example I want to create object X that _needs_ object Y, > then I would have to make a Y accessor. > > X>>y: anY > y := anY > > but this makes no sense as I can still change the `y` object at > later date breaking everything. > > An alternative is having: > > X>>initializeWithY: anY > y := anY. > self initialize. > > X>>y: anY > ^ self basicNew initalizeWithY: anY. > > However I see only 59 initializeWith* methods (in about 6 > packages) compared to 2302 initialize methods. Thus I am deducing > that doing this is not very common. > > Am I missing something or am I trying to unnecessarily constraint > the user and I should just trustâ¢ him that he knows what he should > use? > > As a user of an interface I would prefer not to have useless > things available that would just break things. > > Thanks, > Peter > > >

May 9, 2015

Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1)

by PBKResearch

Sven Thanks for your considered response to my midnight thoughts. I now see the importance of distinguishing the html side (Soup in my work) from the http side (Zinc). I looked at your specimen byte arrays in a Pharo playground, which I am still learning to use; I hadn't seen that proverb in German, but I see the point you are making. Now that my immediate problem is solved, I am not sure whether it is necessary to take up your time any more with it. It depends how many servers do not say what encoding they use, how many sites use encodings other than UTF-8 and how big is the intersection of those sets. If my problem was a one-off, there is no need to go any further. However, there is one general point I would like to make. The debugger is a very good tool for programmers investigating their own code, but it is a very unfriendly place for a user dumped in the middle of someone else's code; yesterday I learned more than I ever wished to about the innards of UTF-8 decoding, before realising it was all irrelevant. If you do think it worth modifying the handling of this case, I would suggest replacing the call to the debugger with a dialog box of some sort, perhaps with debug as an option for the enthusiast, but perhaps also with an option to restart with an alternative encoding. If I can, I would like to ask a supplementary question - I am deeply ignorant but eager to learn. As I mentioned, I tried to get round the problem by downloading the page source to a local file and reading from there into Soup, but this also involved the Zinc decoder and so failed. I tried to see how to get round this, using what I now know about the encoding, and came up with the following: binaryStream := (FileStream readOnlyFileNamed: 'display.html') binary. charStream := ZnCharacterReadStream on: binaryStream encoding: ZnByteEncoder iso88591. hbSoup := Soup fromString: charStream contents. This worked, so in that sense it is OK, but I wonder if there is a neater way of doing it. More importantly, I found that Soup has its own decoder, so I can skip the second line and replace the third by: hbSoup := Soup fromString: binaryStream contents asString. At one stage I found myself looking at a debugger on this process (I know - this contradicts what I said above!), because I had not realised that 'asString' was needed. It looked as though Soup was trying three candidate encodings, which it labelled 'latin1', 'utf-8' and 'cp1252', to find which one would work. It showed the one it had 'sniffed' as most likely being 'latin1', which I think is the same as ISO-8859-1, so it was trying that first. Given this, my question is whether Zinc would allow me to read from a web URL as a binary stream, which I could then feed into the Soup decoder in the same way. If I can, I would use this as my standard procedure; I expect to be visiting a lot of sites, and it would be handy to be able to ignore the encoding issue and hope that Soup can sort it out. Finally, a general comment. Both this query and the one I posed earlier this week, answered by Vincent Blondeau, showed that Pharo users can come to this site and expect quick, friendly and expert help. I am retired and can devote all the time I want to this, but you people must have day jobs as well! I am really very grateful. Best wishes Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 09 May 2015 07:51 To: Any question about pharo is welcome Subject: Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1) > On 09 May 2015, at 02:18, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > Many thanks for the quick response. I always like to try to solve problems myself before appealing for help, so I had worked out what was wrong, but did not know how to tell Zinc to use a specific coding. I had tried by reading through your very full note on Zinc, but did not find the trick you describe - which works perfectly, of course. Good, yes this is a more recent thing. > It seems unfortunate that Zinc does not use the coding specified in the html head. Evidently browsers like Firefox must do it, since the page displays correctly. If it cannot be done, I think it would be helpful to reconsider the error message produced when the user is dumped out, because in this context it is misleading. I spent some time tracing debugger output, trying to work out what was wrong with the UTF-8, before I spotted that one of the bytes was displayed in character form as $Ã¶, and began to suspect it might be a different coding; I finally confirmed this by reading the page source in Firefox. Zn deals with HTTP, not with HTML, these are totally different things, a browser obviously does both. But even then there is no easy way to do this, apart from trying. Consider these two byte arrays: #[85 84 70 56 58 32 68 101 114 32 87 101 103 32 122 117 114 32 72 195 182 108 108 101 32 105 115 116 32 109 105 116 32 103 117 116 101 110 32 86 111 114 115 195 164 116 122 101 110 32 103 101 112 102 108 97 115 116 101 114 116 46] #[73 83 79 56 56 53 57 49 58 32 68 101 114 32 87 101 103 32 122 117 114 32 72 246 108 108 101 32 105 115 116 32 109 105 116 32 103 117 116 101 110 32 86 111 114 115 228 116 122 101 110 32 103 101 112 102 108 97 115 116 101 114 116 46] In them it says how you should decode them! The GT tools make this challenge easy because there is a tab that tries both encodings, but in general this is hard to solve (efficiently). But since Zn does not do HTML, it will never be added at that level. I will think about the error, it might indeed be useful to tell the user that a default encoding was chosen. > Thanks again for your help. You're welcome. > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe > Sent: 08 May 2015 20:04 > To: Any question about pharo is welcome > Subject: Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1) > > Peter, > > Thanks for the URL, it makes it much easier to help you. > > The answer is easy: the server is incorrect, it serves a specific encoding without saying so. > > Consider: > > (ZnClient new > head: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…'; > response) contentType. > > => 'text/html' > > If no charset/encoding is specified, the modern default is UTF-8, so Zn tries that but fails. > > You can change the default for unspecified encoding as follows: > > ZnDefaultCharacterEncoder > value: ZnByteEncoder iso88591 > during: [ > ZnClient new > get: 'http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…' ]. > > The server should have used the following mime type to avoid the confusion: > > ZnMimeType textHtml charSet: #iso88591 > > => 'text/html;charset=iso88591' > > HTH, > > Sven > > PS: the encoding inside the document cannot be used because (1) no interpretation inside documents is done and (2) at that point it is too late, the contents is already converted from bytes to characters > >> On 08 May 2015, at 18:51, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >> Hello >> >> I have been trying to use Soup class>> fromUrl: to access the contents of a web page. It halts with a message from Zinc about malformed UTF-8. The page displays perfectly in Firefox, so I copied the page source from there to a local file and tried to read it from there. Again a message from Zinc: 'Invalid utf8 input detected'. Itâs strange, because the page is not in UTF-8. The head contains: <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">. I have tried to find how to specify the character set in reading files with Zinc, but without success.* >> >> If itâs relevant, I am using Pharo4.0 Latest update: #40613, downloaded two days ago. The address of the web page is: http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr=…. Other pages from the same source are loaded and analysed with no problem. Processing this page seems to go off course as soon as it encounters the character code 246, which is a correct o-umlaut in ISO-8859-1. >> >> Any advice gratefully received. >> >> Peter Kenny >> >> *I would be happy with advice to RTFM, if someone would point out the relevant bit of the FM. > > >

May 9, 2015

Re: [Pharo-users] New fast path for proxy loading in Voyage

by Stephan Eggermont

On 09/05/15 08:48, jtuchel(a)objektfabrik.de wrote: > I do, and I wish Voyage had been available when I had to make a decision > on the persistence mechanism for kontolino.de For bookkeeping you're probably better of with a persistence solution that makes different tradeoffs from those of mongodb. Stephan

May 9, 2015

Re: [Pharo-users] Problem using Zinc in Pharo 4 (Moose 5.1)

by Stephan Eggermont

On 09/05/15 02:18, PBKResearch wrote: > Evidently browsers like Firefox must do it, since the page displays correctly. In my experience with html, if browsers do it, it is probably wrong ;) Stephan

May 9, 2015