- Pharo-users - lists.pharo.org

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

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