December 2016 - Pharo-users

Re: [Pharo-users] NeoJSON will not install on Pharo5

by Brad Selfridge

Hmmmm. I just tried reloading NeoJSON on a Pharo5 image and it prompted me with the message that a newer version was found. I clicked proceed and it installed without errors. Not sure why this happened, but as long as it works. Thank you for your time. ----- Brad Selfridge -- View this message in context: http://forum.world.st/NeoJSON-will-not-install-on-Pharo5-tp4926797p4926814.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 13, 2016

Re: [Pharo-users] real world pharo web application set ups

by Volkert

On 12.12.2016 20:05, Sven Van Caekenberghe wrote: > Yes, it is a bit too wide a subject ;-) > > Anyway, all the cases you find at http://pharo.org/success are successful real-world deployments, but I am sure they are all quite different. i looked already, but there is a problem with the page. all screenshots/pictures have a wrong scaling ... >> On 12 Dec 2016, at 19:52, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Am 12.12.2016 um 19:16 schrieb Volkert <volkert(a)nivoba.de>: >>> >>> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB), performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, .... >>> >>> everything which could important to convince "me" to select pharo as a platform for a saas solution â¦ >>> >> What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo? >> >> Norbert >

Dec. 13, 2016

Re: [Pharo-users] real world pharo web application set ups

by Volkert

On 12.12.2016 19:52, Norbert Hartl wrote: >> Am 12.12.2016 um 19:16 schrieb Volkert <volkert(a)nivoba.de>: >> >> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB), performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, .... >> >> everything which could important to convince "me" to select pharo as a platform for a saas solution â¦ >> > What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo? > > Norbert > > I like to know more about current real world pharo web application set up ... not more, not less. Think of a environmental information management system 50000 User / 500 Concurrent Data Aggregation Data Refinement / Processing Data Visualization 15-20 Dataprovider Web UI

Dec. 13, 2016

Re: [Pharo-users] real world pharo web application set ups

by Joe Shirk

Here is one I am really impressed with; I can't say just how much of it is Pharo: https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a On Tue, Dec 13, 2016 at 12:00 PM, <pharo-users-request(a)lists.pharo.org> wrote: > ------------------ > > Message: 1 > Date: Mon, 12 Dec 2016 19:16:26 +0100 > From: Volkert <volkert(a)nivoba.de> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] real world pharo web application set ups > Message-ID: <7b7e6144-724f-1eb7-8033-8cfe87a34ef6(a)nivoba.de> > Content-Type: text/plain; charset=utf-8; format=flowed > > After reading reading "Enterprise Pharo a Web perspective", i am curious > to learn more about current real world pharo web application set ups. > any case studies or blue prints around? i am interested in application > domain, system architecture, infrastructure (HW/OS/DB), performance > goals (concurrent users, transactions, ...), system sizing, scalability > strategies, .... > > everything which could important to convince "me" to select pharo as a > platform for a saas solution ... > > Thanks, > Volkert > > > > >

Dec. 13, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Ben Coman

On Wed, Dec 14, 2016 at 12:00 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > Fellow Pharoers: What is the most exciting development in 2017 to look > forward to? I'm asking for things to put into the end-of-year post in my > "Make Smalltalk Great Again!" campaign. Thanks. > > Worthwhile 2016 news... - VM sources moved to git. Broadening of VM brand from historical SqueakVM to opensmalltalk-vm serving Squeak, Pharo, Cuis, Newspeak. Pharo 6 release due April 2017. - 64-bit!!! - Sista - adaptive method inlining at the bytecode level https://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-intr… http://www.mirandabanda.org/cogblog/on-line-papers-and-presentations/ Pharo 7 - Iceberg UI interface to git http://www.esug.org/wiki/pier/Conferences/2016/Tuesday/1100-1130-Iceberg - Pharo workflow moving to git. http://forum.world.st/Notes-about-Pharo-6-release-and-new-process-for-Pharo… cheers -ben

Dec. 13, 2016

Re: [Pharo-users] NeoJSON will not install on Pharo5

by Sven Van Caekenberghe

Hi Brad, You mean the catalog browser ? What error do you get, exactly ? You could try loading manually from one of its repositories (http://mc.stfx.eu/Neo or http://smalltalkhub.com/mc/SvenVanCaekenberghe/Neo/main) CI build matrix is all green https://ci.inria.fr/pharo-contribution/job/NeoCSV/ Sven > On 13 Dec 2016, at 18:12, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > NeoJSON will not install from package browser in Pharo5. Is there a work > around? > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/NeoJSON-will-not-install-on-Pharo5-tp4926797.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 13, 2016

Re: [Pharo-users] What can we look forward to in 2017?

by Offray Vladimir Luna CÃ¡rdenas

Hi, As an alternative to "most exciting developments for next year" I would propose "Mapping the place that Smalltalk/Pharo has for you". For example, if someone is interested in data driven storytelling, interactive documentation, reproducible research, and/or data activism, I would think that Grafoscopio[1] is a project to put into the radar. It's also a showcase of both, other Pharo technologies (Roassal, GT-Tools, STON, NeoJSON, WebBrowser, etc.) and, also, how Pharo ecosystem and community can empower learners. [1] http://mutabit.com/grafoscopio/index.en.html Of course others have their own bets about their own projects and why they're important and for who. So my approach would be to prepare kind of a short interview, with some questions that Pharo users/developers could answer to tell the story of their territory explorations on the map that Smalltalk/Pharo has for you. Cheers, Offray On 13/12/16 11:00, horrido wrote: > Fellow Pharoers: What is the most exciting development in 2017 to look > forward to? I'm asking for things to put into the end-of-year post in my > "Make Smalltalk Great Again!" campaign. Thanks. > > > > -- > View this message in context: http://forum.world.st/What-can-we-look-forward-to-in-2017-tp4926791.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 13, 2016

NeoJSON will not install on Pharo5

by Brad Selfridge

NeoJSON will not install from package browser in Pharo5. Is there a work around? ----- Brad Selfridge -- View this message in context: http://forum.world.st/NeoJSON-will-not-install-on-Pharo5-tp4926797.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 13, 2016

Re: [Pharo-users] Hash collision

by Andres Valloud

On 12/10/16 10:36 , Martin McClure wrote: > On 12/09/2016 09:45 AM, Ben Coman wrote: >> >> The suggested fix depended on being willing to let go of byte ordering >> (which we might not want different results on different platforms) >> Float>>hash >> ^ByteArray >> hashBytes: self >> startingWith: self species hash > This fix contains a good idea, but has at least two problems: > 1) The check for integers is important, that's what makes sure that 1.0 > has the same hash as 1. Which it must, since they compare equal. > 2) #hashBytes:startingWith: is designed to hash *bytes*. A BoxedFloat64 > is two *words*, which ensures that when you hashMultiply the high-order > bits of each word get discarded. The high order bits of each word, yes. However, I would have expected the byte oriented code to be, basically, h := some constant. bytes do: [:x | h * 1644525 + x] or h := some constant. bytes do: [:x | h + x * 1644525] In either case, the sign bit in one of the x values should have made a difference. Apparently it didn't. What am I missing here? > I tried implementing a hash that actually uses the bytes of the float > (code at bottom of this message). I didn't do any real analysis of it, > but at least it gives different answers for 0.5 and -0.5. I think it > matches the *intent* of the code above (though would still need the > integer check, which I didn't bother with). Side comment: equality between integers, floats, fractions and other numbers induces a desire to have equal hashes... in my opinion, the resulting complexity hard to justify. >> I see Squeak5's float hash has changed... >> Float>>hash "Squeak5" >> (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self >> truncated hash]. >> ^ ((self basicAt: 1) bitShift: -4) + >> ((self basicAt: 2) bitShift: -4) >> > This is slightly better. It's only discarding eight bits out of 64, > instead of discarding 32. But it would be better to mix all the bits > into the hash. Yes. > Note that all of these hash implementations end up manipulating at least > one large integer most of the time, since each word can be a large > integer. It's possible that a primitive to copy a word object into the > equivalent bytes might speed things up somewhat. ... or use the byte oriented hash. > "Strictly experimental method on BoxedFloat64, could probably be made > faster even without a primitive." > > bytesHash > | bytes word1 word2 | > bytes := ByteArray new: 8. > word1 := self basicAt: 1. > word2 := self basicAt: 2. > bytes at: 1 put: (word1 bitShift: -24). > bytes at: 2 put: ((word1 bitShift: -16) bitAnd: 16rFF). > bytes at: 3 put: ((word1 bitShift: -8) bitAnd: 16rFF). > bytes at: 4 put: (word1 bitAnd: 16rFF). > bytes at: 5 put: (word2 bitShift: -24). > bytes at: 6 put: ((word2 bitShift: -16) bitAnd: 16rFF). > bytes at: 7 put: ((word2 bitShift: -8) bitAnd: 16rFF). > bytes at: 8 put: (word2 bitAnd: 16rFF). > ^ ByteArray hashBytes: bytes startingWith: self class hash I would have expected the floats to be a byte object of size 8. Why is this conversion needed? Is somehow the primitive thinking the float has size 2? Or is the primitive hashing 32 bits at a time? The prim used to be a C version of the byte oriented 1644525 multiplicative hash, did this change? Andres.

Dec. 13, 2016

What can we look forward to in 2017?

by horrido

Fellow Pharoers: What is the most exciting development in 2017 to look forward to? I'm asking for things to put into the end-of-year post in my "Make Smalltalk Great Again!" campaign. Thanks. -- View this message in context: http://forum.world.st/What-can-we-look-forward-to-in-2017-tp4926791.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 13, 2016