December 2016 - Pharo-users

Re: [Pharo-users] Hash collision

by Andres Valloud

The primitive and the primitive failure code should behave the same? On 12/18/16 2:13 , stepharong wrote: > Sorry but how can we improve the situation concretely > > > Stef > > On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: > >> Oh, ok... then the failure code isn't doing what was intended :). >> >> On 12/13/16 15:16 , Martin McClure wrote: >>> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>>> 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? >>> >>> The float is not a byte object of size 8, it's a word object of size 2. >>> >>> When you feed it to #hashBytes:startingWith: the primitive fails. (I >>> didn't look at why -- maybe because it isn't a byte object?) >>> >>> The alternative Smalltalk code treats it like it was a byte object, even >>> though it's not. So it iterates through the two words, multiplying each >>> by 1664525, then keeping only the low-order 28 bits of the result. But >>> since each word is a full 32 bits, the high-order four bits of each >>> word, which include the sign bit, can never affect the hash. >>> >>> Regards, >>> >>> -Martin >>> >> > >

Dec. 18, 2016

Re: [Pharo-users] Modeling a join table

by stepharong

Hi sergio Did you find a solution to your problem? Stef On Tue, 13 Dec 2016 21:59:09 +0100, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Hello, all. > > This question is not as much a question about smalltalk as one about > modeling in smalltalk. > > I am currently writing an API using Teapot that will be serving up data > about internet radio stations. I want to be able to let users tag the > stations with arbitrary tags. Using a >relational database, I would > create an object like "Tagging" with foreign keys pointing to the > "Stations" class and the "Tag" Class. It would have station_id and > tag_id. > > If this was going to be even a tiny bit more complex, I would probably > just make it a polymorphic association. > My question is, how would I approach this in smalltalk? Would I just > make methods on tag and station (and whatever else) that stored arrays > of each other? Would I create an >intermediary model like "Tagging" and > have that do the heavy lifting? > > Ideas? Thanks!; > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

Re: [Pharo-users] Hash collision

by stepharong

Sorry but how can we improve the situation concretely Stef On Wed, 14 Dec 2016 00:22:47 +0100, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Oh, ok... then the failure code isn't doing what was intended :). > > On 12/13/16 15:16 , Martin McClure wrote: >> On 12/13/2016 08:39 AM, Andres Valloud wrote: >>> 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? >> >> The float is not a byte object of size 8, it's a word object of size 2. >> >> When you feed it to #hashBytes:startingWith: the primitive fails. (I >> didn't look at why -- maybe because it isn't a byte object?) >> >> The alternative Smalltalk code treats it like it was a byte object, even >> though it's not. So it iterates through the two words, multiplying each >> by 1664525, then keeping only the low-order 28 bits of the result. But >> since each word is a full 32 bits, the high-order four bits of each >> word, which include the sign bit, can never affect the hash. >> >> Regards, >> >> -Martin >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 18, 2016

whisper code push

by Robert Withers

I just pushed code and I think it is function complete. The encoders available are Bytes, Asn1Der and Json using http://www.squeaksource.com/JSON/ Cryptography-68 Whisper-122 performance numbers by encoder bytes: 123 Mbs json: 5 Mbs asn1der: 5 Mbs I'm off to Java land to integrate these changes.

Dec. 18, 2016

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

by Sven Van Caekenberghe

Mike, > On 17 Dec 2016, at 22:48, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > > On 17 December 2016 at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > [...] >> >> I think I understand your point, and in some specific situations that might be true. But if you can only afford to pay $35 a month for your hardware, how low must your income be ? Are you in a commercially viable enterprise then ? >> >> For a couple of $1000s you can get the equivalent of 10s if not up to 100 of those instances. And that is still much less than office rent, let alone 1 employee. >> >> The challenge today is not the cost of cloud hardware, it is simply building and operating your application. That is assuming you can sell it enough to make a living from it. >> > > > Hi Sven, > > No disagreement. I should clarify that, although I'm writing these > from my old email address, I'm not talking about a software > development company these days. I am now the analyst, programmer, and > system administrator for a long time client, and software is at the > heart of what we do, but we don't make money from it directly. We have > 2.2MLOC of Smalltalk, Common Lisp, Erlang, and PostgreSQL spread over > 30 systems, 20 databases, and 160 data entry terminals. Sounds quite familiar, real world stuff. > So, for example, while we need to sell concert tickets at an opening > peak of 10,000 seats in the first hour 10 times per year, and while we > deploy a dozen hardware-constrained gate admission nodes in a > distributed cluster that must validate up to 1000 tickets per second, > we also have some really complicated personnel scheduling and customer > reporting applications. The former really can't be done in anything > but Erlang where not just hardware but sysadmin cost is a factor. For > the latter, I wouldn't choose anything other than Pharo+Seaside--for > the same reasons you give. Yeah, such peaks are a special case indeed (having been on the buyer side end as well), I would not use Pharo in the direct path there either. > In a nutshell, we have, at times, startup/enterprise-class computing > problems and costs funded by small business revenue. > > Mike It would be interesting to hear more from your applications - please consider contributing a story to http://pharo.org/success - we need them. Thanks for this discussion. Sven

Dec. 17, 2016

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

by Michael J. Forster

On 17 December 2016 at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: [...] > > I think I understand your point, and in some specific situations that might be true. But if you can only afford to pay $35 a month for your hardware, how low must your income be ? Are you in a commercially viable enterprise then ? > > For a couple of $1000s you can get the equivalent of 10s if not up to 100 of those instances. And that is still much less than office rent, let alone 1 employee. > > The challenge today is not the cost of cloud hardware, it is simply building and operating your application. That is assuming you can sell it enough to make a living from it. > Hi Sven, No disagreement. I should clarify that, although I'm writing these from my old email address, I'm not talking about a software development company these days. I am now the analyst, programmer, and system administrator for a long time client, and software is at the heart of what we do, but we don't make money from it directly. We have 2.2MLOC of Smalltalk, Common Lisp, Erlang, and PostgreSQL spread over 30 systems, 20 databases, and 160 data entry terminals. So, for example, while we need to sell concert tickets at an opening peak of 10,000 seats in the first hour 10 times per year, and while we deploy a dozen hardware-constrained gate admission nodes in a distributed cluster that must validate up to 1000 tickets per second, we also have some really complicated personnel scheduling and customer reporting applications. The former really can't be done in anything but Erlang where not just hardware but sysadmin cost is a factor. For the latter, I wouldn't choose anything other than Pharo+Seaside--for the same reasons you give. In a nutshell, we have, at times, startup/enterprise-class computing problems and costs funded by small business revenue. Mike

Dec. 17, 2016

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

by Sven Van Caekenberghe

> On 17 Dec 2016, at 19:39, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > > On 16 December 2016 at 03:15, jtuchel(a)objektfabrik.de > <jtuchel(a)objektfabrik.de> wrote: >> Sven, >> >> Am 16.12.16 um 10:05 schrieb Sven Van Caekenberghe: >>> >>> I did not say we are the fastest, for from it. I absolutely do not want to >>> go into a contest, there is no point in doing so. >> >> Absolutely right. >>> >>> >>> (The dw-bench page was meant to be generated dynamically on each request >>> without caching, did you do that too ?). >>> >>> My point was: Pharo is good enough for most web applications. The rest of >>> the challenge is standard software architecture, design and development. I >>> choose to do that in Pharo because I like it so much. It is perfectly fine >>> by me that 99.xx % of the world makes other decisions, for whatever reason. >> >> Exactly. Smalltalk and Seaside are perfectly suited for web applications and >> are not per se extremely slow or anything. >> Raw benchmarks are some indicator, but whether a web applicaton is fast or >> slow depends so much more on your applications' architecture than the >> underlying HTTP handling stuff. >> >> The important question is not "how fast can Smalltalk serve a number of >> bytes?" but "how fast can your application do whatever is needed to put >> those bytes together?". >> >> So your benchmarks show that Smalltalk can serve stuff more than fast enough >> for amost all situations (let's be honest, most of us will never have to >> server thousands of concurrent users - of course I hope I am wrong ;-) ). >> The rest is application architecture, infrastructure and avoiding stupid >> errors. Nothing Smalltalk specific. >> >> >> Joachim >> > [...] > > > In our benchmarking and production experience, Pharo--even with > Seaside--has fared well against Common Lisp, Java, Ruby, and Erlang > web applications in terms of _page delivery speed_. Erlang positively > embarrasses the others at handling concurrent requests, and it does so > extremely cost-effectively in terms of hardware. Pharo (and Seaside) > does likewise, at the other end of the spectrum, when developing > sophisticated application workflow. > > And that's the inflection point--a painful one--for us. To experience > such effective time to market and maintenance, grow, and then trade it > all to scale to 500+ concurrent users on a single t2.medium instance > to keep hardware costs in check. I think I understand your point, and in some specific situations that might be true. But if you can only afford to pay $35 a month for your hardware, how low must your income be ? Are you in a commercially viable enterprise then ? For a couple of $1000s you can get the equivalent of 10s if not up to 100 of those instances. And that is still much less than office rent, let alone 1 employee. The challenge today is not the cost of cloud hardware, it is simply building and operating your application. That is assuming you can sell it enough to make a living from it. > Mike

Dec. 17, 2016

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

by Michael J. Forster

On 16 December 2016 at 03:15, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > Sven, > > Am 16.12.16 um 10:05 schrieb Sven Van Caekenberghe: >> >> I did not say we are the fastest, for from it. I absolutely do not want to >> go into a contest, there is no point in doing so. > > Absolutely right. >> >> >> (The dw-bench page was meant to be generated dynamically on each request >> without caching, did you do that too ?). >> >> My point was: Pharo is good enough for most web applications. The rest of >> the challenge is standard software architecture, design and development. I >> choose to do that in Pharo because I like it so much. It is perfectly fine >> by me that 99.xx % of the world makes other decisions, for whatever reason. > > Exactly. Smalltalk and Seaside are perfectly suited for web applications and > are not per se extremely slow or anything. > Raw benchmarks are some indicator, but whether a web applicaton is fast or > slow depends so much more on your applications' architecture than the > underlying HTTP handling stuff. > > The important question is not "how fast can Smalltalk serve a number of > bytes?" but "how fast can your application do whatever is needed to put > those bytes together?". > > So your benchmarks show that Smalltalk can serve stuff more than fast enough > for amost all situations (let's be honest, most of us will never have to > server thousands of concurrent users - of course I hope I am wrong ;-) ). > The rest is application architecture, infrastructure and avoiding stupid > errors. Nothing Smalltalk specific. > > > Joachim > [...] In our benchmarking and production experience, Pharo--even with Seaside--has fared well against Common Lisp, Java, Ruby, and Erlang web applications in terms of _page delivery speed_. Erlang positively embarrasses the others at handling concurrent requests, and it does so extremely cost-effectively in terms of hardware. Pharo (and Seaside) does likewise, at the other end of the spectrum, when developing sophisticated application workflow. And that's the inflection point--a painful one--for us. To experience such effective time to market and maintenance, grow, and then trade it all to scale to 500+ concurrent users on a single t2.medium instance to keep hardware costs in check. Mike

Dec. 17, 2016

Re: [Pharo-users] Unscheduled outage for http://ss3.gemtalksystems.com/ and http://seaside.gemtalksystems.com/ss

by Dale Henrichs

sites are back on-line ... On 12/17/16 9:09 AM, Dale Henrichs wrote: > The colo where the hardware is located had announced scheduled > maintenance for our cluster, but there was not supposed to be any > downtime ... we are looking into the problem > > Dale >

Dec. 17, 2016

Re: [Pharo-users] [Vm-dev] ptsd rage

by Tudor Girba

Hi Robert, I am really sorry to hear your condition, and indeed, I hope you will find a remedy. Thank you very much for this email. I can imagine it was hard to write it. Cheers, Tudor > On Dec 17, 2016, at 2:57 AM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > I need to apologize for all my dread behavior. Here is the reason, and I am on service-connected disability. Current diagnosis is Complex PTSD. Sorry about all my sturm und drang. > > http://www.ptsd.va.gov/public/problems/anger-and-trauma.asp > > > Sincerely, > > Robert > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Dec. 17, 2016