- Pharo-dev - lists.pharo.org

Zeroconf - Slowness & Cloudflare
by phil＠highoctane.be March 3, 2014

March 3, 2014

loading files from files.pharo.org seems to be slower than before (zeroconf for me). What about a mirror on Cloudflare? The free plan would do: http://www.cloudflare.com/plans http://www.cloudflare.com/features-cdn Phil

2 1

understanding postgresv2
by Tudor Girba March 3, 2014

March 3, 2014

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"

5 10

hashMultiply
by phil＠highoctane.be March 3, 2014

March 3, 2014

I am currently reading through the Hashing in Smalltalk book ( 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 :-) 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. I had a look at how it was done in VisualWorks; 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. As a side note, how is one debugging such methods? Looks like the debugger (in 2.0) doesn't like SmallIntegers (I can understand why due to the specific nature of the object but still. Ok, Also VW marks it as a primitive, which Pharo does not. 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 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) 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

3 8

WhatsUp from: 2014-03-03 until: 2014-03-16
by seaside＠rmod.lille.inria.fr March 3, 2014

March 3, 2014

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-03-16 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

1 0

Versioneer docs?
by phil＠highoctane.be March 2, 2014

March 2, 2014

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

2 1

[Bug] IdentitySet>>size
by Max Leske March 2, 2014

March 2, 2014

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

2 4

Zinc bug submitting form via GET?
by Sean P. DeNigris March 2, 2014

March 2, 2014

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.

3 6

FLMaterializer Materialization error
by Lorenzo Baracchi March 2, 2014

March 2, 2014

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. Is there a way to know in which version of fuel a file was written and use that version to read it? thanks Lorenzo

4 8

[ANN] Fuel 1.9.3
by Max Leske March 2, 2014

March 2, 2014

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

6 7

Help needed! ClassTest>>#testRenaming
by Nicolai Hess March 2, 2014

March 2, 2014

Hope we can sort this out, more and more fixes suffer from the wrong testing failures and nothing new gets integrated. 12996 <https://pharo.fogbugz.com/default.asp?12996>ClassTest>>#testRenaming leaves dirty package Dummy-Tests-Class behind 12995 <https://pharo.fogbugz.com/default.asp?12995> CI ClassTest>>#testRenaming is failing available options: 1. skip test 2. test for nil in RPackageOrganizer>>#systemClassRenamedActionFrom: before rPackage updateDefinedClassNamed: oldName withNewName: newName. 3. review changes for issue 12601 (fix RPackageOrganizer>>#systemCategoryRemovedActionFrom: ann, to unregister packages even if there are MCPackages (don't know about the side effects) best solution would be number 3, but the recent submissions for issue 12601 are quite complex, so I don't know. Nicolai

3 3