March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] hashMultiply

by Andres Valloud

Once the code is loaded, from the Tools menu use Hash Analysis Tool. There's a manual below, and also the Fundamentals book has a somewhat in depth discussion on how it works. ftp://sqrmax.us.to/pub/Smalltalk/Papers/Hash%20Analysis%20Tool.pdf On 3/2/14 15:06 , phil(a)highoctane.be wrote: > I have found the tools in the Cincom public repo. > > Now, I have to see how this works in VW, I am not that proficient with it. > > Phil > > > > On Wed, Feb 26, 2014 at 8:55 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>> wrote: > > Andres, > > Thanks for the insights. > > hash quality is indeed an key factor. At least, my mind is somewhat > grasping this hashing field a bit better. > > I'll have a look at the tools, I haven't used them yet. > > And a shot at the ASM version with NativeBoost in Pharo. > > For what occurs in modern CPUs, well, no. Surprising to see that a > mul would be faster than a shr or shl. How comes? > I used to be ok with these things when I was writing demoscene code > a loong time ago but I'd need an extremely serious refresh. > > As a side note, there is a huge uptake in the > BigData/mapreduce/hadoop environment where Smalltalk is sorely > absent. Scala seems to fill the void on the JVM. > There hashing is quite key, to remap all of the mapping phase > results to the reduce nodes. I am surprised to see that Smalltalk > vendors haven't jumped in that space. > > Phil > > > On Wed, Feb 26, 2014 at 2:04 AM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net > <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: > > Hello... > > On 2/25/14 1:17 , phil(a)highoctane.be <mailto:phil@highoctane.be> > wrote: > > I am currently reading through the Hashing in Smalltalk book > (http://www.lulu.com/shop/__andres-valloud/hashing-in-__smalltalk-theory-and… > <http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-pra…>__) > and, my head hurting notwithstanding, there are indeed a ton > of gems in > this system. As he mentions, doing the exercises brings a > lot of extra :-) > > > :) thank you. > > When going to 64-bit, and with the new ObjectMemory scheme, > I guess a > couple of identity hashing functions will come under scrutiny. > > e.g. > > SmallInteger>>hashMultiply > | low | > > low := self bitAnd: 16383. > ^(16r260D * low + ((16r260D * (self bitShift: -14) + > (16r0065 * low) > bitAnd: 16383) * 16384)) > bitAnd: 16r0FFFFFFF > > > which will need some more bits. > > > IMO it's not clear that SmallInteger>>identityHash should be > implemented that way. Finding a permutation of the small > integers that also behaves like a good quality hash function and > evaluates quickly (in significantly less time and complexity > than, say, Bob Jenkins' lookup3) would be a really interesting > research project. I don't know if it's possible. If no such > thing exists, then getting at least some rough idea of what's > the minimum necessary complexity for such hash functions would > be valuable. > > Looking at hashMultiply as a non-identity hash function, one > would start having problems when significantly more than 2^28 > objects are stored in a single hashed collection. 2^28 objects > with e.g. 12 bytes per header and a minimum of one instance > variable (so the hash value isn't a instance-constant) stored in > a hashed collection requires more than 4gb, so that is clearly a > 64 bit image problem. In 64 bits, 2^28 objects with e.g. 16 > bytes per header and a minimum of one instance variable each is > already 6gb, and a minimum of 8gb with the hashed collection itself. > > Because of these figures, I'd think improving the implementation > of hashed collections takes priority over adding more > non-identity hash function bits (as long as the existing hash > values are of good quality). > > Did you look at the Hash Analysis Tool I wrote? It's in the > Cincom public Store repository. It comes in two bundles: Hash > Analysis Tool, and Hash Analysis Tool - Extensions. With > everything loaded, the tool comes with 300+ hash functions and > 100+ data sets out of the box. The code is MIT. > > I had a look at how it was done in VisualWorks; > > > The implementation of hashMultiply, yes. Note however that > SmallInteger>>hash is ^self. > > hashMultiply > "Multiply the receiver by 16r0019660D mod 2^28 > without using large integer arithmetic for speed. > The constant is a generator of the multiplicative > subgroup of Z_2^30, see Knuth's TAOCP vol 2." > <primitive: 1747> > | low14Bits | > low14Bits := self bitAnd: 16r3FFF. > ^16384 > * (16r260D * (self bitShift: -14) + (16r0065 * low14Bits) > bitAnd: 16r3FFF) > + (16r260D * low14Bits) bitAnd: 16rFFFFFFF > > The hashing book version has: > > multiplication > "Computes self times 1664525 mod 2^38 while avoiding > overflow into a > large integer by making the multiplication into two 14 bits > chunks. Do > not use any division or modulo operation." > | lowBits highBits| > > lowBits := self bitAnd: 16r3FFF. > highBits := self bitShift: -14. > ^(lowBits * 16r260D) > + (((lowBits * 16r0065) bitAnd: 16r3FFF) bitShift: 14) > + (((highBits * 16r260D) bitAnd: 16r3FFF) bitShift: 14) > bitAnd: 16rFFFFFFF > > So, 16384 * is the same as bitShift: 14 and it looks like > done once, > which may be better. > > > It should be a primitive (or otherwise optimized somehow). At > some point though that hash function was implemented for e.g. > ByteArray in Squeak, I thought at that point the multiplication > step was also implemented as a primitive? > > Also VW marks it as a primitive, which Pharo does not. > > > In VW it is also a translated primitive, i.e. it's executed > directly in the JIT without calling C. > > Keep in mind that the speed at which hash values are calculated > is only part of the story. If the hash function quality is not > great, or the hashed collection implementation is not efficient > and induces collisions or other extra work, improving the > efficiency of the hash functions won't do much. I think it's > mentioned in the hash book (I'd have to check), but once I made > a hash function 5x times slower to get better quality and the > result was that a report that was taking 30 minutes took 90 > seconds instead (and hashing was gone from the profiler output). > > Would we gain > some speed doing that? hashMultiply is used a lof for > identity hashes. > > Bytecode has quite some work to do: > > 37 <70> self > 38 <20> pushConstant: 16383 > 39 <BE> send: bitAnd: > 40 <68> popIntoTemp: 0 > 41 <21> pushConstant: 9741 > 42 <10> pushTemp: 0 > 43 <B8> send: * > 44 <21> pushConstant: 9741 > 45 <70> self > 46 <22> pushConstant: -14 > 47 <BC> send: bitShift: > 48 <B8> send: * > 49 <23> pushConstant: 101 > 50 <10> pushTemp: 0 > 51 <B8> send: * > 52 <B0> send: + > 53 <20> pushConstant: 16383 > 54 <BE> send: bitAnd: > 55 <24> pushConstant: 16384 > 56 <B8> send: * > 57 <B0> send: + > 58 <25> pushConstant: 268435455 > 59 <BE> send: bitAnd: > 60 <7C> returnTop > > > If this is a primitive instead, then you can also avoid the > overflow into large integers and do the math with (basically) > > mov eax, smallInteger > shr eax, numberOfTagBits > mul eax, 1664525 "the multiplication that throws out the high bits" > shl eax, 4 "throw out bits 29-32" > shr eax, 4 > lea eax, [eax * 2^numberOfTagBits + smallIntegerTagBits] > > Please excuse trivial omissions in the above, it's written only > for the sake of illustration (e.g. it looks like the 3 last > instructions can be combined into two... lea followed by shr). > Also, did you see the latency of integer multiplication > instructions in modern x86 processors?... > > I ran some experiments timing things. > > It looks like that replacing 16384 * by bitShift:14 leads to > a small > gain, bitShift (primitive 17) being faster than * (primitive 9) > > > Keep in mind those operations still have to check for overflow > into large integers. In this case, large integers are not > necessary. > > Andres. > > The bytecode is identical, except send: bitShift instead of > send: * > > multiplication3 > | low | > > low := self bitAnd: 16383. > ^(16r260D * low + ((16r260D * (self bitShift: -14) + > (16r0065 * low) > bitAnd: 16383) bitShift: 14)) > bitAnd: 16r0FFFFFFF > > > > [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 12 > [500000 timesRepeat: [ 15000 multiplication ]] timeToRun 41 > (worse) > [500000 timesRepeat: [ 15000 multiplication3 ]] timeToRun 10 > (better) > > It looks like correct for SmallInteger minVal to: > SmallInteger maxVal > > Now, VW gives: [500000 timesRepeat: [ 15000 hashMultiply ]] > timeToRun > 1.149 milliseconds > > Definitely worth investigating the primitive thing, or some > NB Asm as > this is used about everywhere (Collections etc). > > Toughts? > > Phil > > > >

March 2, 2014

Re: [Pharo-dev] understanding postgresv2

by Yanni Chiu

Hmmm. Didn't remember that was there. IIRC, it was released under Squeak Licence, via SqueakMap. Then when migrated to squeaksource.com, I believe it was marked as MIT. I've lost track of where it's being actively maintained, but please go ahead and remove or update the copyright text in the comment to MIT. -- Yanni On 02/03/2014 11:36 AM, Tudor Girba wrote: > Another thing I see in the comment of PGConnection is this: > Copyright (c) 2001-2003 by Yanni Chiu. All Rights Reserved. > > Does anyone know the actual license? > > Doru > > > On Sun, Mar 2, 2014 at 5:34 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi, > > I am trying to understand how PostgresV2 is implemented because I > would like to build some inspector support for it, and I encounter a > couple of issues. In case anyone knows the answer, it would speed up > my effort: > > - Why is result an instance variable in PGConnection? Making it a > variable always returns the same object when executing a query and > that is a bit of a pain. > > - Why does the PGResult have the possibility of holding multiple > PGResultSets? When is it possible to have multiple at the same time? > (when you execute a query, the result is being initialized) > > - When running something like > connection execute: 'select * from ...' > the PGResultSet already includes all rows of the query. Is it not > possible to have a stream-like functionality in which the actual > rows are retrieved only on demand? (a similar functionality exists > in DBXTalk) > > - What is the difference between PGAsciiRow and PGDataRow? > > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

March 2, 2014

Re: [Pharo-dev] hashMultiply

by phil＠highoctane.be

I have found the tools in the Cincom public repo. Now, I have to see how this works in VW, I am not that proficient with it. Phil On Wed, Feb 26, 2014 at 8:55 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Andres, > > Thanks for the insights. > > hash quality is indeed an key factor. At least, my mind is somewhat > grasping this hashing field a bit better. > > I'll have a look at the tools, I haven't used them yet. > > And a shot at the ASM version with NativeBoost in Pharo. > > For what occurs in modern CPUs, well, no. Surprising to see that a mul > would be faster than a shr or shl. How comes? > I used to be ok with these things when I was writing demoscene code a > loong time ago but I'd need an extremely serious refresh. > > As a side note, there is a huge uptake in the BigData/mapreduce/hadoop > environment where Smalltalk is sorely absent. Scala seems to fill the void > on the JVM. > There hashing is quite key, to remap all of the mapping phase results to > the reduce nodes. I am surprised to see that Smalltalk vendors haven't > jumped in that space. > > Phil > > > On Wed, Feb 26, 2014 at 2:04 AM, Andres Valloud < > avalloud(a)smalltalk.comcastbiz.net> wrote: > >> Hello... >> >> On 2/25/14 1:17 , phil(a)highoctane.be wrote: >> >>> I am currently reading through the Hashing in Smalltalk book >>> (http://www.lulu.com/shop/andres-valloud/hashing-in- >>> smalltalk-theory-and-practice/paperback/product-3788892.html) >>> and, my head hurting notwithstanding, there are indeed a ton of gems in >>> this system. As he mentions, doing the exercises brings a lot of extra >>> :-) >>> >> >> :) thank you. >> >> When going to 64-bit, and with the new ObjectMemory scheme, I guess a >>> couple of identity hashing functions will come under scrutiny. >>> >>> e.g. >>> >>> SmallInteger>>hashMultiply >>> | low | >>> >>> low := self bitAnd: 16383. >>> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) >>> bitAnd: 16383) * 16384)) >>> bitAnd: 16r0FFFFFFF >>> >>> >>> which will need some more bits. >>> >> >> IMO it's not clear that SmallInteger>>identityHash should be implemented >> that way. Finding a permutation of the small integers that also behaves >> like a good quality hash function and evaluates quickly (in significantly >> less time and complexity than, say, Bob Jenkins' lookup3) would be a really >> interesting research project. I don't know if it's possible. If no such >> thing exists, then getting at least some rough idea of what's the minimum >> necessary complexity for such hash functions would be valuable. >> >> Looking at hashMultiply as a non-identity hash function, one would start >> having problems when significantly more than 2^28 objects are stored in a >> single hashed collection. 2^28 objects with e.g. 12 bytes per header and a >> minimum of one instance variable (so the hash value isn't a >> instance-constant) stored in a hashed collection requires more than 4gb, so >> that is clearly a 64 bit image problem. In 64 bits, 2^28 objects with e.g. >> 16 bytes per header and a minimum of one instance variable each is already >> 6gb, and a minimum of 8gb with the hashed collection itself. >> >> Because of these figures, I'd think improving the implementation of >> hashed collections takes priority over adding more non-identity hash >> function bits (as long as the existing hash values are of good quality). >> >> Did you look at the Hash Analysis Tool I wrote? It's in the Cincom >> public Store repository. It comes in two bundles: Hash Analysis Tool, and >> Hash Analysis Tool - Extensions. With everything loaded, the tool comes >> with 300+ hash functions and 100+ data sets out of the box. The code is >> MIT. >> >> I had a look at how it was done in VisualWorks; >>> >> >> The implementation of hashMultiply, yes. Note however that >> SmallInteger>>hash is ^self. >> >> hashMultiply >>> "Multiply the receiver by 16r0019660D mod 2^28 >>> without using large integer arithmetic for speed. >>> The constant is a generator of the multiplicative >>> subgroup of Z_2^30, see Knuth's TAOCP vol 2." >>> <primitive: 1747> >>> | low14Bits | >>> low14Bits := self bitAnd: 16r3FFF. >>> ^16384 >>> * (16r260D * (self bitShift: -14) + (16r0065 * low14Bits) bitAnd: >>> 16r3FFF) >>> + (16r260D * low14Bits) bitAnd: 16rFFFFFFF >>> >>> The hashing book version has: >>> >>> multiplication >>> "Computes self times 1664525 mod 2^38 while avoiding overflow into a >>> large integer by making the multiplication into two 14 bits chunks. Do >>> not use any division or modulo operation." >>> | lowBits highBits| >>> >>> lowBits := self bitAnd: 16r3FFF. >>> highBits := self bitShift: -14. >>> ^(lowBits * 16r260D) >>> + (((lowBits * 16r0065) bitAnd: 16r3FFF) bitShift: 14) >>> + (((highBits * 16r260D) bitAnd: 16r3FFF) bitShift: 14) >>> bitAnd: 16rFFFFFFF >>> >>> So, 16384 * is the same as bitShift: 14 and it looks like done once, >>> which may be better. >>> >> >> It should be a primitive (or otherwise optimized somehow). At some point >> though that hash function was implemented for e.g. ByteArray in Squeak, I >> thought at that point the multiplication step was also implemented as a >> primitive? >> >> Also VW marks it as a primitive, which Pharo does not. >>> >> >> In VW it is also a translated primitive, i.e. it's executed directly in >> the JIT without calling C. >> >> Keep in mind that the speed at which hash values are calculated is only >> part of the story. If the hash function quality is not great, or the >> hashed collection implementation is not efficient and induces collisions or >> other extra work, improving the efficiency of the hash functions won't do >> much. I think it's mentioned in the hash book (I'd have to check), but >> once I made a hash function 5x times slower to get better quality and the >> result was that a report that was taking 30 minutes took 90 seconds instead >> (and hashing was gone from the profiler output). >> >> Would we gain >>> some speed doing that? hashMultiply is used a lof for identity hashes. >>> >>> Bytecode has quite some work to do: >>> >>> 37 <70> self >>> 38 <20> pushConstant: 16383 >>> 39 <BE> send: bitAnd: >>> 40 <68> popIntoTemp: 0 >>> 41 <21> pushConstant: 9741 >>> 42 <10> pushTemp: 0 >>> 43 <B8> send: * >>> 44 <21> pushConstant: 9741 >>> 45 <70> self >>> 46 <22> pushConstant: -14 >>> 47 <BC> send: bitShift: >>> 48 <B8> send: * >>> 49 <23> pushConstant: 101 >>> 50 <10> pushTemp: 0 >>> 51 <B8> send: * >>> 52 <B0> send: + >>> 53 <20> pushConstant: 16383 >>> 54 <BE> send: bitAnd: >>> 55 <24> pushConstant: 16384 >>> 56 <B8> send: * >>> 57 <B0> send: + >>> 58 <25> pushConstant: 268435455 >>> 59 <BE> send: bitAnd: >>> 60 <7C> returnTop >>> >> >> If this is a primitive instead, then you can also avoid the overflow into >> large integers and do the math with (basically) >> >> mov eax, smallInteger >> shr eax, numberOfTagBits >> mul eax, 1664525 "the multiplication that throws out the high bits" >> shl eax, 4 "throw out bits 29-32" >> shr eax, 4 >> lea eax, [eax * 2^numberOfTagBits + smallIntegerTagBits] >> >> Please excuse trivial omissions in the above, it's written only for the >> sake of illustration (e.g. it looks like the 3 last instructions can be >> combined into two... lea followed by shr). Also, did you see the latency >> of integer multiplication instructions in modern x86 processors?... >> >> I ran some experiments timing things. >>> >>> It looks like that replacing 16384 * by bitShift:14 leads to a small >>> gain, bitShift (primitive 17) being faster than * (primitive 9) >>> >> >> Keep in mind those operations still have to check for overflow into large >> integers. In this case, large integers are not necessary. >> >> Andres. >> >> The bytecode is identical, except send: bitShift instead of send: * >>> >>> multiplication3 >>> | low | >>> >>> low := self bitAnd: 16383. >>> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) >>> bitAnd: 16383) bitShift: 14)) >>> bitAnd: 16r0FFFFFFF >>> >>> >>> >>> [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 12 >>> [500000 timesRepeat: [ 15000 multiplication ]] timeToRun 41 (worse) >>> [500000 timesRepeat: [ 15000 multiplication3 ]] timeToRun 10 (better) >>> >>> It looks like correct for SmallInteger minVal to: SmallInteger maxVal >>> >>> Now, VW gives: [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun >>> 1.149 milliseconds >>> >>> Definitely worth investigating the primitive thing, or some NB Asm as >>> this is used about everywhere (Collections etc). >>> >>> Toughts? >>> >>> Phil >>> >> >> >

March 2, 2014

Re: [Pharo-dev] Versioneer docs?

by Christophe Demarey

Hi Phil, Le 1 mars 2014 Ã 16:50, phil(a)highoctane.be a Ã©crit : > I am now porting my code to 3.0 > > I am using Versioneer to look at my configuration as when I do load it in 3.0, it seems that there are some duplicate packages coming in my package-cache and I want to remove these dupes. (Mostly Seaside related). > > Versioneer is very helpful in representing the configuration. > > Now, is there any doc about its usage? You can find some documentation here: http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner Don't hesitate to give feedback. Versionner gets better with feedbacks I got latest weeks. Maybe you already know but you can use the record directive with Metacello to see what will be loaded, i.e. resolved dependencies from the configuration: https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr…. It may help to debug. Best regards, Christophe.

March 2, 2014

Re: [Pharo-dev] [Bug] IdentitySet>>size

by Max Leske

On 02.03.2014, at 22:55, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > So, just out of curiosity, how does the IdentitySet get "damagedâ? Thatâs what Iâd like to know too :) Nicolai posted an update to the issue which should shed some light on the problem. But at the moment I have no clue. Iâm hoping that somebody has worked with those tests and knows something. > > On 3/2/14 11:28 , Max Leske wrote: >> >> On 02.03.2014, at 20:12, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >>> So it seems the problem is with Fuel rather than IdentitySet, no? >> >> No. Asking an IdentitySet for its size is not reliable. That has nothing to do with Fuel. #size is especially important in hashed collections where the size is stored in a variable and thus allows fast access the size without the need to visit every element in the collection for its computation. >> >>> >>> On 3/2/14 10:47 , Max Leske wrote: >>>> During serialization the IdentitySet size is stored and later its objects. During that step, #do: >>> >> >> >> >

March 2, 2014

Re: [Pharo-dev] [Bug] IdentitySet>>size

by Andres Valloud

So, just out of curiosity, how does the IdentitySet get "damaged"? On 3/2/14 11:28 , Max Leske wrote: > > On 02.03.2014, at 20:12, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > >> So it seems the problem is with Fuel rather than IdentitySet, no? > > No. Asking an IdentitySet for its size is not reliable. That has nothing to do with Fuel. #size is especially important in hashed collections where the size is stored in a variable and thus allows fast access the size without the need to visit every element in the collection for its computation. > >> >> On 3/2/14 10:47 , Max Leske wrote: >>> During serialization the IdentitySet size is stored and later its objects. During that step, #do: >> > > >

March 2, 2014

Re: [Pharo-dev] [Bug] IdentitySet>>size

by Max Leske

On 02.03.2014, at 20:12, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > So it seems the problem is with Fuel rather than IdentitySet, no? No. Asking an IdentitySet for its size is not reliable. That has nothing to do with Fuel. #size is especially important in hashed collections where the size is stored in a variable and thus allows fast access the size without the need to visit every element in the collection for its computation. > > On 3/2/14 10:47 , Max Leske wrote: >> During serialization the IdentitySet size is stored and later its objects. During that step, #do: >

March 2, 2014

Re: [Pharo-dev] [Bug] IdentitySet>>size

by Andres Valloud

So it seems the problem is with Fuel rather than IdentitySet, no? On 3/2/14 10:47 , Max Leske wrote: > During serialization the IdentitySet size is stored and later its objects. During that step, #do:

March 2, 2014

[Bug] IdentitySet>>size

by Max Leske

Hi Fuel kept throwing strange errors at me the last couple of days. I now found that IdentitySet>>size is not correct for some instances in the image and canât be fixed with #rehash (checked with newest image on newest PharoVM). I noticed that #rehash only replaces âarray' while âtallyâ stays untouched (but âtallyâ holds the wrong sizeâ¦). Notice that all those instances seem to be related to tests (their elements are all Metaclass objects of test classes). Hereâs how to get the (16) corrupted instances: IdentitySet allInstances select: [ :e | e size ~= (e collect: #yourself) size ] Why this causes problems for Fuel: During serialization the IdentitySet size is stored and later its objects. During that step, #do: will evaluate the block less often than it should, based on size (e.g. size is 3, but âarrayâ only holds 2 objects). During materialization all the offsets after an IdentitySet object in the stream are off because of this. FogBugz issue: https://pharo.fogbugz.com/f/cases/13026/IdentitySet-size-reports-wrong-size Cheers, Max

March 2, 2014

Re: [Pharo-dev] Zinc bug submitting form via GET?

by Sven Van Caekenberghe

Sean, On 02 Mar 2014, at 12:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Sean, > > On 02 Mar 2014, at 06:49, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> In porting the Mechanize web scraping library from Ruby, I started with the >> following example: >> a.get('http://google.com/') do |page| >> search_result = page.form_with(:name => 'f') do |search| >> search.q = 'Hello world' >> end.submit >> >> It GETs >> http://www.google.com/search?ie=ISO-8859-1&hl=en&source=hp&q=Hello+world&gb… >> >> I tried to do that with Zinc via formAt: name put:, but when I sent #get, >> the query was empty and the response was another blank search form. It took >> me some time to figure out what was going on and change to #queryPut:at: in >> the GET case, but now I'm managing form logic from the outside. Since GET is >> valid for forms (apparently it is the default per >> http://www.w3schools.com/tags/att_form_method.asp) it seems Zinc should >> handle this more gracefully. I would expect it to check for form fields and >> add them to the query when doing a GET. What do you think? > > Cool that you are trying to do a project like that. > > The reason this fails is because it is explicitly prevented in ZnClient>>#method:! If you go there and remove the whole #ifTrue:, sending entities with a GET and your example will work. > > Making the change, one unit test fails ZnClientTest>>#testGetAfterPost and that is why the code is there: if you re-use a ZnClient instance (with its connection) to the same (REST) host, you are also re-using the request object, and then you don't want to carry over entities from a previous request. This is a feature that we use internally all the time. > > I have to think about the best solution: like make this an option, and which would best be the default. I'll come back to you. In #bleedingEdge: === Name: Zinc-HTTP-SvenVanCaekenberghe.391 Author: SvenVanCaekenberghe Time: 2 March 2014, 7:19:50.045159 pm UUID: 39686b36-3c95-430f-9f2d-bfe3d8db00b9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.390 Added ZnClient #autoResetEntityMethods to control for which methods #resetEntity happens automatically (in #method:), the default being #(HEAD DELETE). This happened previously on GET as well, but that conflicted with the fact that web forms can be submitted using a GET with an entity body (thx Sean DeNigris); Removed all #asTimeStamp calls === Name: Zinc-Tests-SvenVanCaekenberghe.204 Author: SvenVanCaekenberghe Time: 2 March 2014, 7:20:38.944687 pm UUID: adf6fed8-b440-4517-8215-6184d5255725 Ancestors: Zinc-Tests-SvenVanCaekenberghe.203 Added ZnClient #autoResetEntityMethods to control for which methods #resetEntity happens automatically (in #method:), the default being #(HEAD DELETE). This happened previously on GET as well, but that conflicted with the fact that web forms can be submitted using a GET with an entity body (thx Sean DeNigris); Removed all #asTimeStamp calls === In particular, the new ZnClientTests>>#testGetForm functional unit test covers your case. Regards, Sven > Thanks for the feedback, > > Sven > >> n.b. Gofer it >> smalltalkhubUser: 'SeanDeNigris' project: 'Mechanize'; >> package: 'Mechanize'; >> load. >> >> >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Zinc-bug-submitting-form-via-GET-tp4747276.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 2, 2014