- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Segmentation fault while installing Scale

by Andrey Tykhonov

Hello, > Hi, > We are looking at it with Santi. I see in the log that you're using an ubuntu 12? No, this is Gentoo Linux. > I tried in a debian jessie and Santi in an ubuntu 14 and we could not > reproduce it. Also the travis ci of scale uses ubuntu 12 and the > installation works in there... > Could you give more details about your system? Sure, but I'm not sure which exactly information will be useful, so, please clarify. For now, I'm sending you kernel version: $ uname -a Linux tp 4.9.6-gentoo #1 SMP Thu Jan 26 17:04:47 EET 2017 x86_64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz GenuineIntel GNU/Linux > Thanks, Guille and Santi Thank you! -- Andriy

Feb. 10, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Andrey Tykhonov

Hi Clement, > Hi Andrey, > Thanks for providing both a way to reproduce and the log so we can have you > machine details. I see that the VM was compiled from build #589 on jenkins > with VMMaker.oscog-eem.1855 and you're on Linux using x86 back-end. > Scale works only on Linux and when I try the wget command from Mac it does > not work so I can't reproduce right now. > I suggest that for now you try to use one of the newer VMs (from > http://files.pharo.org/vm/pharo-spur32/linux/ , you're > using stable-20160504.zip, pick another one, It seems, the latest VM is downloaded. It is downloaded by means of the following command: wget -O - get.pharo.org/50+vm | bash Does it download old VM. Is this script outdated? I suggest a more recent one > than from May last year, either stable-20160623.zip > or pharo-linux-i386itimer-201702061308-aa78f27.zip) and then use the > "classic installation" to be able to use another VM than the one downloaded > by the wget script until someone can have a look into your problem. Could you please help, where could I get Pharo.image file which is required to execute pharo/pharo-ui? If I use existing one (with a VM taken from either stable-20160623.zip or pharo-linux-i386itimer-201702061308-aa78f27.zip), the VM crashes. So, it seems, I need another Pharo.image as well, right? With the best regards, Andriy

Feb. 10, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Andrey Tykhonov

Hi stephane > can you tell us on which OS and version This is Gentoo Linux. There is no such a thing like a version. There are kernel and a lot of software. Kernel version: # uname -a Linux tp 4.9.6-gentoo #1 SMP Thu Jan 26 17:04:47 EET 2017 x86_64 Intel(R) Core(TM) i7-6700HQ CPU @ 2 I found crash.dmp near pharo-ui,.60GHz GenuineIntel GNU/Linux Let me know please if I could provide more info on this matter. > and which VM do you use (there is a System report browser where you can find the information. It is downloaded by means of the command: wget -O - get.pharo.org/50+vm | bash AFAIU, the latest VM is downloaded by means of this command. I opened pharo-ui: ./pharo-ui Pharo.image > pharo.log and it was opened for a while, but it crashed when I tried to get information from System report browser. After that, I cannot open pharo-ui anymore. Two log files are attached to this email. Best regards, Andriy

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by Dimitris Chloupis

Actually your numbers are pretty low #blendercoders indeed has 187 , but those are the actual C coders working on the blender source (which I do not do), so its an equivalent of our phraro-dev, the equivalent of pharo-users is #blender with 360 members and the #blenderpython with 70 members which are people like me that work on blender addons using python (all these are online users of course) BUT.... the blender community is enormous, its theorised since its impossible to know for sure that is around 1 million users, both professional and hobbists. As a result of this the community is highly fragmanted as all community of similar size are because they are impossible to be contained. In Discord I am on 2 blender servers one has 175 online users and the other 75 online users. As such I have little reason anymore to use IRC and especially Slack (the only thing in Slack of interest to me is Pharo). Also I am a game developer and Discord has become the default online chat tool for game developers and gamers aline the same way Slack has become the default online chat tool for developers. Unreal server I am using on Discord has over 1200 users online , countless dedicate channels and a great deal of Unreal game developers use Blender so for me Discord by far the best choice for what I am doing. Also a problem with IRC is that you see people that are online but they never say a word so they are online but always AFK. In Discord if you are afk there is a yellow icon to indicate that , from what I am seeing people participating in Discord tend to be far more active than people participating in IRC. On Fri, Feb 10, 2017 at 6:46 PM Hilaire <hilaire(a)drgeo.eu> wrote: > I just saw Blender developers seems to use IRC (#blendercoders @ > irc.freenode.net) 187 users. Ruby too at #ruby 917 users > > Le 10/02/2017 Ã 12:29, Dimitris Chloupis a Ã©crit : > > e) for personal reason.... all my favorite software (Blender, Unreal > > etc) is using it > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 10, 2017

Re: [Pharo-dev] Slack, fragmentation and design information

by Esteban A. Maringolo

2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Mass adoption and hyper reduced friction to get people on board. > > For me: I have 10+ slack teams in my slack client and there is really no > point in having more clients on the desktop. +1 to this. This is key. Maybe what we're missing is a simple wiki to collect the shared knowledge, recipes, and other stuff. Esteban A. Maringolo

Feb. 10, 2017

Re: [Pharo-dev] Slack, fragmentation and design information

by phil＠highoctane.be

Mass adoption and hyper reduced friction to get people on board. For me: I have 10+ slack teams in my slack client and there is really no point in having more clients on the desktop. Phil On Fri, Feb 10, 2017 at 5:30 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Please excuse my ignorance but what are the advantages of Slack over > other instant messaging system like IRC or Jabber? > > Hilaire > > Le 10/02/2017 Ã 10:27, Stephan Eggermont a Ã©crit : > > The past year we have started using Slack to communicate in real-time > > about Pharo. It has nice (mobile) clients and makes it easy to share > > pictures and snippets. As a result a large part of the communication > about > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by Hilaire

I just saw Blender developers seems to use IRC (#blendercoders @ irc.freenode.net) 187 users. Ruby too at #ruby 917 users Le 10/02/2017 Ã 12:29, Dimitris Chloupis a Ã©crit : > e) for personal reason.... all my favorite software (Blender, Unreal > etc) is using it -- Dr. Geo http://drgeo.eu

Feb. 10, 2017

Re: [Pharo-dev] Slack, fragmentation and design information

by Hilaire

Please excuse my ignorance but what are the advantages of Slack over other instant messaging system like IRC or Jabber? Hilaire Le 10/02/2017 Ã 10:27, Stephan Eggermont a Ã©crit : > The past year we have started using Slack to communicate in real-time > about Pharo. It has nice (mobile) clients and makes it easy to share > pictures and snippets. As a result a large part of the communication about -- Dr. Geo http://drgeo.eu

Feb. 10, 2017

Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo

by ClÃ©ment Bera

Well the 64 bits VM is optimised for 61 bits signed integers instead of 31 bits signed integers, so bit operations on integers between 32 bits and 61 bits should get faster. In addition, some operations are optimised for unsigned machine word, and therefore the VM can use unsigned 64 bits integers instead of unsigned 32 bits integer. I am glad you enjoyed my blog post. Note that since I wrote it, I replaced (following a discussion between Eliot and Levente) the special selector #blockCopy: which has been unused for the past 9 years by #'~~' to have consistent behavior between #'~~' and #'=='. Latest VMs should have this feature. Best, Clement On Fri, Feb 10, 2017 at 1:21 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Oh! Many thanks for all the details! I thought about special selectors > and remembered that #bitAnd: and #bitOr: were those special kind of > "beasts" but I falsely assumed that #bitXor: was also a special selector... > :( I should have looked at the code! > > So that also explains the "strange" behavior of the 64bit image. Lots of > the tests in the 32bit image fell into the LargeInteger "range" and then, > executing the same code on the 64bit image, those numbers suddenly became > considered SmallInteger... That explains it all and why some operations > "suddenly" became so fast for no apparent reason !!! > > Now, just for my personal curiosity, what is going to be the impact of a > 64bit VM on such code? (Unfortunately, I am on Windows so I will have to > wait...) ? > > P.S. I should have persevered in my google searches as I just came across > this *excellent* post : Arithmetic, inlined and special selectors > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special…> > > :) > > Thanks a lot! > > Arithmetic, inlined and special selectors > Today we are going to discuss how message sends are dispatched in the VM > and/or compiled in the image for arithm... > > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special…> > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > ------------------------------ > *From:* ClÃ©ment Bera <bera.clement(a)gmail.com> > *To:* Benoit St-Jean <bstjean(a)yahoo.com>; Pharo Development List < > pharo-dev(a)lists.pharo.org> > *Cc:* The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org> > *Sent:* Friday, February 10, 2017 5:14 AM > *Subject:* Re: [Pharo-dev] Integer arithmetic and bit counting > performance in Squeak and Pharo > > Hi, > > This is a lovely post. Thanks for posting about Smalltalk / Pharo / Squeak. > > > 1. Why *exactly* does the override work (in 32bit images)? > 2. What changed so that things are different in Squeak 5.1 64bit image > (overrides partially work)? > > If I am correct your questions are exclusively for bitOr: and bitAnd:. I > don't know what you are aware of and what you're not aware of, hence I am > going to give you some details on how bitAnd: is executed (bitOr: is done > exactly the same way), and hopefully there will be something you don't know > yet that should help you understand what's going on. > > *Execution of bitAnd:* > > bitAnd: a special selector. If you run Smalltalk specialSelectors you get > this array: #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 > #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 > #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0 #blockCopy: 1 #value 0 #value: > 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) which includes bitAnd: . > > Special selectors are encoded in the bytecode differently to save memory, > so they can be executed differently without inducing overhead. In Cog, > bitAnd: is executed differently using type-prediction. > > In the Stack Interpreter, the execution of bitAnd: is done as follows: > If both operands are SmallIntegers, > push the bitAnd: value of the 2 SmallIntegers > else > Try the primitive BitAnd for SmallIntegers (14) > on success > push the result > on failure > perform the send. > > In the JIT, bitAnd: sends are compiled differently that normal send, the > compilation logic is as follows: > If both operands are SmallInteger literals > compute the result during compilation and use this value > else > If one of the 2 operands is a SmallInteger literal > generate 2 paths, a quick inlined path testing at runtime that > the other operand is a SmallInteger, and if so, Ands the operands and use > that result, else use the slow path performing a send > else > generate a normal send > > *Primitives* > > primitive 14 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned machine word. (Slower than direct SmallInteger bitAnd > performed by the special selector) > primitive 34 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned int64. (Slower than primitive 14 in 32 bits but covering > more cases, equivalent in 64 bits) > primDigitBitAnd (in Integer) -> Works for any integer. (Slower than the > primitive 14 and 34) > > *SmallInteger encoding* > > In 32 bits, SmallIntegers are signed 31bits integer. > In 64 bits, SmallIntegers are signed 61 bits integer. > > *Discussion* > > Let's make some assertions based on previous information: > > 1) If you have the exact same bitAnd: implementation for #bitAnd: and > #bitAnd2:, #bitAnd2: is slower because it is not a special selector. > > 2) Still with the exact same bitAnd: implementation, using the JIT, things > like that: > 16r1 bitAnd: 1. "1 bits" > 16r2 bitAnd: 2. "2 bit" > 16r4 bitAnd: 4. "3 bit" > 16r8 bitAnd: 3. "4 bit" > Are bitAnd: operations between SmallInteger constants and the result is > unused. Hence this whole portion of code does not generate any native > instructions. > On the other hand, things like that: > 16r1 bitAnd2: 1. "1 bits" > 16r2 bitAnd2: 2. "2 bit" > 16r4 bitAnd2: 4. "3 bit" > 16r8 bitAnd2: 3. "4 bit" > Are sends, generating multiple native instructions including calls. > > 3) Because of the SmallInteger encoding, > 16r200000000000000 bitAnd: 98490667780264321. "58 bit" > is compiled by the JIT to nothing in 64 bits but to a send in 32 bits (the > JIT can't solve LargeInteger arithmetic at compilation time). > > 4) primitive 34 provides some speed-up over primitive 14 in 32 bits, > covering bitAnd: operations from unsigned 33 bits integer to unsigned 64 > bits integer, but makes no difference in 64 bits. In 64bits all the cases > covered by primitive 34 are covered by primitive 14, so it should even slow > down things. > > *So...* > > Does this answer your questions ? > Don't hesitate to ask further questions. > > If you want more details, I wrote something about special selectors a > while ago: https://clementbera.wordpress.com/2014/08/12/ > arithmetic-inlined-and-special-selectors/ . > > Best, > > Clement > > PS1: If I'm correct, you referenced my blog a couple times, thank you for > doing this, I really appreciate that. > PS2: I enjoy chess myself, so if you have an open-source/MIT working > algorithm at some point please send it to me, I will play against the AI > and look at the code. > > > On Fri, Feb 10, 2017 at 8:18 AM, Benoit St-Jean via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org <squeak-dev(a)lists.squeakfoundation.org>>, " > pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> > Cc: > Date: Fri, 10 Feb 2017 07:18:02 +0000 (UTC) > Subject: Integer arithmetic and bit counting performance in Squeak and > Pharo > For those interested in performance of bit operations and integer > arithmetic in Squeak and Pharo : > > Bit operations in general : https://endormitoire.wordpress > .com/2017/02/10/bits-and- pieces/ > <https://endormitoire.wordpress.com/2017/02/10/bits-and-pieces/> > > Bit counting algorithms : https://endormitoire.wordpress > .com/2017/02/10/1001001-sos/ > <https://endormitoire.wordpress.com/2017/02/10/1001001-sos/> > > Some questions, some results, some answers... > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > > >

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by FranÃ§ois Stephany

There is a special price for non-profits organization: > The Slack for Nonprofits program offers eligible organizations a *free upgrade* to our Standard plan for teams of up to 250 members. For eligible teams above that size, we offer an 85% discount on the Standard plan. With 322 users it means that we still have to pay... See https://get.slack.help/hc/en-us/articles/204368833-Slack-for-Nonprofits for more information. On Fri, Feb 10, 2017 at 1:18 PM, denker <marcus.denker(a)inria.fr> wrote: > > > > >> I share many of what you sayâ¦ but in the other point of view, Slack as > really worked and there is a lot more happening now in Slack + mailing list > than what was before just in mailing list. > >> But most of that is lost because of Slack policies (also Slack pricing > model is impossible for a community as ours), and we need to find a > solution for that. > > > > Yes this is too expensive for the Pharo consortium ? > > > It is per active memberâ¦ which is defined as âhas logged in the last 14 > daysâ. We have 322 members. No idea how many > are active according to that definition. > > Fot 322 it would be: $8 per user per month. Which means $2576 per month or > $25772 per year (taking the special yearly price into account). > > Marcus > > >

Feb. 10, 2017