- Pharo-dev - lists.pharo.org

understanding postgresv2

by Tudor Girba

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 "Every thing has its own flow"

March 2, 2014

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

by Pharo4Stef

On 02 Mar 2014, at 12:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Pharo4Stef wrote >> Sean how it is different from Soup? > > It adds a layer from a web browsing POV, so you can say "#submit this form" > and "#click the link whose text #beginsWith: 'Whatever'". I used Soup > underneath, since it is the very forgiving of the underlying html is > malformed. Ok I looked a bit at mechanize. Looks nice. > > > Pharo4Stef wrote >> Do you write tests? > > Yes. Excellent! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Zinc-bug-submitting-form-via-GET-tp4747276p4747311.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 2, 2014

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

by Sven Van Caekenberghe

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. 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

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

by Sean P. DeNigris

Pharo4Stef wrote > Sean how it is different from Soup? It adds a layer from a web browsing POV, so you can say "#submit this form" and "#click the link whose text #beginsWith: 'Whatever'". I used Soup underneath, since it is the very forgiving of the underlying html is malformed. Pharo4Stef wrote > Do you write tests? Yes. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Zinc-bug-submitting-form-via-GET-tp4747276p4747311.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 2, 2014

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

by Pharo4Stef

which parser will you use to parse HTML? 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? > > 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

Re: [Pharo-dev] FLMaterializer Materialization error

by Max Leske

https://code.google.com/p/fuel/issues/detail?id=207 On 27.02.2014, at 17:06, Max Leske <maxleske(a)gmail.com> wrote: > > On 27.02.2014, at 16:52, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 27 Feb 2014, at 3:45 , Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> >>> >>> >>> On Thu, Feb 27, 2014 at 11:32 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> On 27.02.2014, at 14:54, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 27, 2014 at 10:48 AM, Lorenzo Baracchi <baracchi.lorenzo(a)gmail.com> wrote: >>>> Hi >>>> >>>> I was using FLMaterializer materializationFromFileNamed: filename to read fuel files. >>>> Until yesterday everything was fine, but today I updated Pharo and received the error "'Materialization error. Unexpected stream version 19 where it should be 193." >>>> >>>> I guess that a new version of fuel cannot (simply) read old versions files. >>>> >>>> This is the "default" exception. But maybe....between 1.9 and 1.9.2 the file format didn't change. Max? >>> >>> I think 1.9 to 1.9.3 should work without problems. I canât think of any changes to the file format. >>> >>> >>> An interesting idea for Fuel would be that for each released version, besides defining the version, we also define the list of previous versions that are known to work with this one. So for example, we could say that 1.9.3 should work ok up to 1.9. So upon materialization we check this info. This would be very cool. Of course, it is our responsibility (humans/developers) to define with which previous versions it should workâ¦ >> >> A versioning scheme that encodes much of the needed information directly is great for this. >> >> An example: >> >> X.Y.Z-[Dialect/Version] >> X - Major version changes, can not be expected to read streams of previous versions correctly (changed storage format for something) >> Y - Minor version changes, can be expected to read older versions, but not newer, correctly (added new capabilities to the format, such as new hooks etc.) >> Z - Internal changes/bugfixes, (no changes to the actual serialization format) >> [Dialect/Version] - Not needed for error recovery if classes of serialized instances are included, as that is better to use directly if encountering missing/incompatible definitions, but a nice bit of info to start from otherwise... >> > > +1 > Thatâs also easy to understand for users. > >> Cheers, >> Henry

March 2, 2014

Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3

by Max Leske

On 01.03.2014, at 23:14, Max Leske <maxleske(a)gmail.com> wrote: > > On 01.03.2014, at 18:46, phil(a)highoctane.be wrote: > >> So Debugger -> Smalltalk tools debugger needed... >> > Thanks Phil, I missed that somehow. Debugger is now SpecDebugger. Iâll fix it. Fixed. > >> >> Le 1 mars 2014 14:19, "Sebastian Sastre" <sebastian(a)flowingconcept.com> a Ã©crit : >> great job you guys >> >> sebastian >> >> o/ >> >> On 01/03/2014, at 02:23, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >>> Thanks for the update. >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> 2014-02-26 18:13 GMT-03:00 Max Leske <maxleske(a)gmail.com>: >>> Dear fellow Smalltalkers >>> >>> Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially announced): >>> >>> - (feature) the #fuelReplacement selector offers the ability to statically replace an object (e.g. with nil) during analysis. This can lead to significantly smaller graphs and improved speed when serializing large graphs >>> - (feature) serialize the same graph that was analyzed instead of retrazing the graph during serialization. This prevents changes in the graph from happening between analysis and serialization >>> - (change) store source when serializing CompiledMethod objects. Needed because Opal does not allow decompilation >>> - (fix) migrate variables across hierarchy >>> - (feature) Object>>serializeToFileNamed: shortcut for serializing arbitrary objects >>> - (fix) better compression for LargeNegativeIntegers (https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg…) >>> >>> Pharo30 already includes most of these changes (integration request: https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3) >>> >>> This release runs with: >>> - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 >>> - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 >>> >>> The documentation is not up to date yet but we will remedy that situatoin within the next couple of days (http://rmod.lille.inria.fr/web/pier/software/Fuel) >>> If you encounter any bugs or have suggestions, please contact us on the Fuel mailing list (http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create a new issue in our bug tracker (https://code.google.com/p/fuel/) >>> >>> We want to thank everyone who contributed to this release (by keyboard or opinion) and also all of those people who actively use Fuel. >>> >>> Cheers, >>> Max >>> >

March 2, 2014

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

by Pharo4Stef

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 Cool. Sean how it is different from Soup? Do you write tests? > > 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? > > 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

Re: [Pharo-dev] Help needed! ClassTest>>#testRenaming

by btc＠openinworld.com

March 2, 2014

Zinc bug submitting form via GET?

by Sean P. DeNigris

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? 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