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

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

by Esteban Lorenzano

> On 09 May 2015, at 08:48, jtuchel(a)objektfabrik.de wrote: > > Esteban, > > Am 09.05.15 um 08:26 schrieb Esteban Lorenzano: >> >>> On 09 May 2015, at 07:54, jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote: >>> >>> Hi guys, >>> >>> I am fascinated by Voyage and was about to take a look at how much effort it might be to port it to VA Smalltalk for a project that doesn't have the option of moving away from it. >> >> thatâs cool, I never hear about people using it in other dialects :) > > Not yet. But I can think of uses for it on a project. I am at an early stage >> >>> >>> If I understand correctly, I can now give up on the idea, because Voyage will be using Slots from now on. Am I right? >> >> wellâ¦ eventually, that will happen, I suppose I will replace the magritte package with slotsâ¦ but: > > You mean Magritte, but not related to Voyage, right? >> >> 1) that will not happen any time soon (at least, just now in Pharo5 we are starting to create the tools to take advantage of slotsâ¦ so I guess it will be ready âfor general consumptionâ in pharo6â¦ not that we cannot do some experimental stuff, and we will, but I do not thing there will be a replacement for magritte right now) >> 2) even if I do that, nothing forbids other dialect users to keep maintaining/using the magritte branch >> >> nowâ¦ recent changes from Henrik are meant to take advantage not from slots but the fast-become made by Igor, a become who just works in > > Okay, so I misunderstood the use of the word "Slots" in some messages of this thread. > >> the case of two objects of same size (in that case, it just swap the objects and do not update the full system). This is hopefully a temporal change (while we wait for spur, who implements a general fast become)â¦ I guess this can be rewritten without using the slot builder, but in any case this is too pharo specific to help youâ¦ nothing prevents you to do a âcompatibility packageâ that overrides that method and allows you to continue using Voyage. >> Please letâs me know if you do it and you make your packages public for VA users. >> > I'll have to see if this new change makes porting harder (it is hard already ;-) ). This will not happen very soon, but it is on my todo list. > If I do it, it will be published on VASTGoodies. well.. it is just a method :) also, Iâm not sure you didnât need to adapt it before (because it uses forward become) >> thanks, glad you find it useful :) >> > > I do, and I wish Voyage had been available when I had to make a decision on the persistence mechanism for kontolino.de <http://kontolino.de/> > > Joachim > >> Esteban >> >>> >>> Joachim >>> >>> Am 08.05.15 um 15:14 schrieb Henrik Johansen: >>>> >>>>> On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >>>>> Hi Esteban! >>>>> As we talked about on IRC yesterday, I had hoped to employ the fast become discussed in >>>>> http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455…> >>>>> to bring faster proxy loading untill Spur arrives. >>>>> Sadly, it's not present in any current VM's, for reasons unknown*. >>>>> >>>>> Luckily, the alternative proposed by Levente in the original thread (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370… <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…>) is appropriate for our case. >>>>> As I don't have write-access to Voyage repo, I've attached the package with the changes (which work in both 3.0 and 4.0, but I assume not older, due to using the SlotBuilder for anon subclasses) >>>>> >>>>> >>>>> hahahahah excellent. It was similar to the same idea I have for my proxies in Marea. In my case, what I did is to have 3 types of Proxies (each with each different object "format" -> normal, compact, long), and each of those proxy classes was a "variableSubclass". So then when I received the object to proxify, I would create an instance (the correct one from one of those 3 proxy classes) of the size of the object to proxify. Therefore, both, the proxy and the target would have same size and format, and therefore I could simply apply Igor idea. >>>> >>>> Yeah, it's a really nice fast-path, when the VM's become implementation usually involves a heap scan... >>>> >>>> In the case of Voyage, we're restricted in that we don't start out with a database ID, and not the actual original object, so perfectly pre-shaping the proxy is impossible. >>>> Variably sized objects are right out, so I settled on the compromise that was easy to do; fixed size objects with equal or greater number of instvars as the proxy class. >>>> >>>> To do fast swapping with objects of less than 3 slots, the current data held in proxy slots would have to be held somewhere external, which is doable, but ugly. >>>> (You can also work around this easily if the performance hit is noticeable by adding dummy slots...) >>>> Compact proxies is a really limited use case, since you never store any of the builtin ones in buckets directly, you'd have to manually make your mapped classes compact. >>>> >>>> Seeing as how it's really just a holdover performance hack till Spur is ready for use and become: becomes fast, I don't think it makes sense implementing either in the context of Voyage. >>>> >>>> Cheers, >>>> Henry >>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> >>> Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

May 9, 2015

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

by Sven Van Caekenberghe

> 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 jtuchel＠objektfabrik.de

Esteban, Am 09.05.15 um 08:26 schrieb Esteban Lorenzano: > >> On 09 May 2015, at 07:54, jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> wrote: >> >> Hi guys, >> >> I am fascinated by Voyage and was about to take a look at how much >> effort it might be to port it to VA Smalltalk for a project that >> doesn't have the option of moving away from it. > > thatâs cool, I never hear about people using it in other dialects :) Not yet. But I can think of uses for it on a project. I am at an early stage > >> >> If I understand correctly, I can now give up on the idea, because >> Voyage will be using Slots from now on. Am I right? > > wellâ¦ eventually, that will happen, I suppose I will replace the > magritte package with slotsâ¦ but: You mean Magritte, but not related to Voyage, right? > > 1) that will not happen any time soon (at least, just now in Pharo5 we > are starting to create the tools to take advantage of slotsâ¦ so I > guess it will be ready âfor general consumptionâ in pharo6â¦ not that > we cannot do some experimental stuff, and we will, but I do not thing > there will be a replacement for magritte right now) > 2) even if I do that, nothing forbids other dialect users to keep > maintaining/using the magritte branch > > nowâ¦ recent changes from Henrik are meant to take advantage not from > slots but the fast-become made by Igor, a become who just works in Okay, so I misunderstood the use of the word "Slots" in some messages of this thread. > the case of two objects of same size (in that case, it just swap the > objects and do not update the full system). This is hopefully a > temporal change (while we wait for spur, who implements a general fast > become)â¦ I guess this can be rewritten without using the slot builder, > but in any case this is too pharo specific to help youâ¦ nothing > prevents you to do a âcompatibility packageâ that overrides that > method and allows you to continue using Voyage. > Please letâs me know if you do it and you make your packages public > for VA users. > I'll have to see if this new change makes porting harder (it is hard already ;-) ). This will not happen very soon, but it is on my todo list. If I do it, it will be published on VASTGoodies. > thanks, glad you find it useful :) > I do, and I wish Voyage had been available when I had to make a decision on the persistence mechanism for kontolino.de Joachim > Esteban > >> >> Joachim >> >> Am 08.05.15 um 15:14 schrieb Henrik Johansen: >>> >>>> On 08 May 2015, at 2:12 , Mariano Martinez Peck >>>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen >>>> <henrik.s.johansen(a)veloxit.no >>>> <mailto:henrik.s.johansen@veloxit.no>> wrote: >>>> >>>> Hi Esteban! >>>> As we talked about on IRC yesterday, I had hoped to employ the >>>> fast become discussed in >>>> http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… >>>> to bring faster proxy loading untill Spur arrives. >>>> Sadly, it's not present in any current VM's, for reasons unknown*. >>>> >>>> Luckily, the alternative proposed by Levente in the original >>>> thread >>>> (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…) >>>> is appropriate for our case. >>>> As I don't have write-access to Voyage repo, I've attached the >>>> package with the changes (which work in both 3.0 and 4.0, but I >>>> assume not older, due to using the SlotBuilder for anon subclasses) >>>> >>>> >>>> hahahahah excellent. It was similar to the same idea I have for my >>>> proxies in Marea. In my case, what I did is to have 3 types of >>>> Proxies (each with each different object "format" -> normal, >>>> compact, long), and each of those proxy classes was a >>>> "variableSubclass". So then when I received the object to proxify, >>>> I would create an instance (the correct one from one of those 3 >>>> proxy classes) of the size of the object to proxify. Therefore, >>>> both, the proxy and the target would have same size and format, and >>>> therefore I could simply apply Igor idea. >>> >>> Yeah, it's a really nice fast-path, when the VM's become >>> implementation usually involves a heap scan... >>> >>> In the case of Voyage, we're restricted in that we don't start out >>> with a database ID, and not the actual original object, so perfectly >>> pre-shaping the proxy is impossible. >>> Variably sized objects are right out, so I settled on the compromise >>> that was easy to do; fixed size objects with equal or greater number >>> of instvars as the proxy class. >>> >>> To do fast swapping with objects of less than 3 slots, the current >>> data held in proxy slots would have to be held somewhere external, >>> which is doable, but ugly. >>> (You can also work around this easily if the performance hit is >>> noticeable by adding dummy slots...) >>> Compact proxies is a really limited use case, since you never store >>> any of the builtin ones in buckets directly, you'd have to manually >>> make your mapped classes compact. >>> >>> Seeing as how it's really just a holdover performance hack till Spur >>> is ready for use and become: becomes fast, I don't think it makes >>> sense implementing either in the context of Voyage. >>> >>> Cheers, >>> Henry >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de >> Fliederweg 1http://www.objektfabrik.de >> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 9, 2015

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

by Esteban Lorenzano

> On 09 May 2015, at 07:54, jtuchel(a)objektfabrik.de wrote: > > Hi guys, > > I am fascinated by Voyage and was about to take a look at how much effort it might be to port it to VA Smalltalk for a project that doesn't have the option of moving away from it. thatâs cool, I never hear about people using it in other dialects :) > > If I understand correctly, I can now give up on the idea, because Voyage will be using Slots from now on. Am I right? wellâ¦ eventually, that will happen, I suppose I will replace the magritte package with slotsâ¦ but: 1) that will not happen any time soon (at least, just now in Pharo5 we are starting to create the tools to take advantage of slotsâ¦ so I guess it will be ready âfor general consumptionâ in pharo6â¦ not that we cannot do some experimental stuff, and we will, but I do not thing there will be a replacement for magritte right now) 2) even if I do that, nothing forbids other dialect users to keep maintaining/using the magritte branch nowâ¦ recent changes from Henrik are meant to take advantage not from slots but the fast-become made by Igor, a become who just works in the case of two objects of same size (in that case, it just swap the objects and do not update the full system). This is hopefully a temporal change (while we wait for spur, who implements a general fast become)â¦ I guess this can be rewritten without using the slot builder, but in any case this is too pharo specific to help youâ¦ nothing prevents you to do a âcompatibility packageâ that overrides that method and allows you to continue using Voyage. Please letâs me know if you do it and you make your packages public for VA users. > > That's a pity. Nevertheless, keep up the good work! > Voyage and Mongo are really a promising and terribly easy to use persistence mechanism! I immediately fell in love when I played with it. thanks, glad you find it useful :) Esteban > > Joachim > > Am 08.05.15 um 15:14 schrieb Henrik Johansen: >> >>> On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> >>> >>> On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >>> Hi Esteban! >>> As we talked about on IRC yesterday, I had hoped to employ the fast become discussed in >>> http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455…> >>> to bring faster proxy loading untill Spur arrives. >>> Sadly, it's not present in any current VM's, for reasons unknown*. >>> >>> Luckily, the alternative proposed by Levente in the original thread (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370… <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…>) is appropriate for our case. >>> As I don't have write-access to Voyage repo, I've attached the package with the changes (which work in both 3.0 and 4.0, but I assume not older, due to using the SlotBuilder for anon subclasses) >>> >>> >>> hahahahah excellent. It was similar to the same idea I have for my proxies in Marea. In my case, what I did is to have 3 types of Proxies (each with each different object "format" -> normal, compact, long), and each of those proxy classes was a "variableSubclass". So then when I received the object to proxify, I would create an instance (the correct one from one of those 3 proxy classes) of the size of the object to proxify. Therefore, both, the proxy and the target would have same size and format, and therefore I could simply apply Igor idea. >> >> Yeah, it's a really nice fast-path, when the VM's become implementation usually involves a heap scan... >> >> In the case of Voyage, we're restricted in that we don't start out with a database ID, and not the actual original object, so perfectly pre-shaping the proxy is impossible. >> Variably sized objects are right out, so I settled on the compromise that was easy to do; fixed size objects with equal or greater number of instvars as the proxy class. >> >> To do fast swapping with objects of less than 3 slots, the current data held in proxy slots would have to be held somewhere external, which is doable, but ugly. >> (You can also work around this easily if the performance hit is noticeable by adding dummy slots...) >> Compact proxies is a really limited use case, since you never store any of the builtin ones in buckets directly, you'd have to manually make your mapped classes compact. >> >> Seeing as how it's really just a holdover performance hack till Spur is ready for use and become: becomes fast, I don't think it makes sense implementing either in the context of Voyage. >> >> Cheers, >> Henry > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >

May 9, 2015

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

by jtuchel＠objektfabrik.de

Hi guys, I am fascinated by Voyage and was about to take a look at how much effort it might be to port it to VA Smalltalk for a project that doesn't have the option of moving away from it. If I understand correctly, I can now give up on the idea, because Voyage will be using Slots from now on. Am I right? That's a pity. Nevertheless, keep up the good work! Voyage and Mongo are really a promising and terribly easy to use persistence mechanism! I immediately fell in love when I played with it. Joachim Am 08.05.15 um 15:14 schrieb Henrik Johansen: > >> On 08 May 2015, at 2:12 , Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >> On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen >> <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> >> wrote: >> >> Hi Esteban! >> As we talked about on IRC yesterday, I had hoped to employ the >> fast become discussed in >> http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… >> to bring faster proxy loading untill Spur arrives. >> Sadly, it's not present in any current VM's, for reasons unknown*. >> >> Luckily, the alternative proposed by Levente in the original >> thread >> (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…) >> is appropriate for our case. >> As I don't have write-access to Voyage repo, I've attached the >> package with the changes (which work in both 3.0 and 4.0, but I >> assume not older, due to using the SlotBuilder for anon subclasses) >> >> >> hahahahah excellent. It was similar to the same idea I have for my >> proxies in Marea. In my case, what I did is to have 3 types of >> Proxies (each with each different object "format" -> normal, compact, >> long), and each of those proxy classes was a "variableSubclass". So >> then when I received the object to proxify, I would create an >> instance (the correct one from one of those 3 proxy classes) of the >> size of the object to proxify. Therefore, both, the proxy and the >> target would have same size and format, and therefore I could simply >> apply Igor idea. > > Yeah, it's a really nice fast-path, when the VM's become > implementation usually involves a heap scan... > > In the case of Voyage, we're restricted in that we don't start out > with a database ID, and not the actual original object, so perfectly > pre-shaping the proxy is impossible. > Variably sized objects are right out, so I settled on the compromise > that was easy to do; fixed size objects with equal or greater number > of instvars as the proxy class. > > To do fast swapping with objects of less than 3 slots, the current > data held in proxy slots would have to be held somewhere external, > which is doable, but ugly. > (You can also work around this easily if the performance hit is > noticeable by adding dummy slots...) > Compact proxies is a really limited use case, since you never store > any of the builtin ones in buckets directly, you'd have to manually > make your mapped classes compact. > > Seeing as how it's really just a holdover performance hack till Spur > is ready for use and become: becomes fast, I don't think it makes > sense implementing either in the context of Voyage. > > Cheers, > Henry -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 9, 2015

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

by Ben Coman

On Sat, May 9, 2015 at 8:18 AM, 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. > > 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. Now we have moldable tools by default, I wonder if ZnResponse (which I guess typically people will inspect while troubleshooting) might have a tab called something like "Someone Else's Problem" or "Protocol Errors". cheers -ben > 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. > > Thanks again for your help. > > 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] Problem using Zinc in Pharo 4 (Moose 5.1)

by PBKResearch

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. 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. Thanks again for your help. 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] Roassal multiline popupText ?

by Alexandre Bergel

hi Phil! As Nicolai said, it is supported. Try: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 7, 2015, at 3:52 PM, phil(a)highoctane.be wrote: > > I'd love to have multiline popupText. > > dsEvents := RTDataSet new. > dsEvents interaction > popupText: [ :point | > > 'coll: {1} - ts: {2} / {3} -- {4} - {5}' > format: { > key. > (point ts asSeconds - start) printString. > .... > > How can I do that? > > Looks like the thing is single line. > > > TIA > Phil >

May 8, 2015

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

by Sven Van Caekenberghe

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 8, 2015

Re: [Pharo-users] Roassal Camp Smalltalk, July 12

by Alexandre Bergel

> I would add some interests like using Roassal to build data narratives (see some examples at [1]) and the integration to end user "apps" (grafoscopio[2]) where Roassal is a core part of the experience > > [1] http://mutabit.com/offray/static/blog/output/posts/visualizing-politiciansp… > [2] http://mutabit.com/grafoscopio/ Yes, this is an important topic as well!! Embedding Roassal into larger application is crucial in many situations. > If you wish to participate, get in touch with us. Since we will probably have a >> sponsoring of the event, it would be nice to know how many will attend to ease >> the logistic and the pizza ordering :-) >> > > Sponsoring means having the possibility to attend to the event? I have made consistently workshops and hackathons using Roassal (we will have more all Saturdays of May and we're planning one week long workshop in June) and I think that learning from others in place could be a significant improvement in the way I can spread the knowledge and make a stronger local community in Colombia... So just showing my interest in attending to have the proper time in getting my visa ready ;-) Sponsoring means we will likely have snacks and drinks. But it all depends :-) Alexandre

May 8, 2015