November 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60289 Home: https://github.com/pharo-project/pharo-core

Nov. 11, 2016

Re: [Pharo-dev] [ANN] Pharo Association has a new Website!

by Marcus Denker

Hi, I have already started to improve the integration between the sites. - Contribute has now the Join form embedded: http://pharo.org/contribute - not directly related, but http://pharo.org/community now has the form to subscribe to the newsletter embedded. More to be done, step by step... On Thu, Nov 10, 2016 at 2:25 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > That's nice, we have donate button now. Is it possible to make it more > visible? Or at least put it in pharo.org > > > 2016-11-10 10:22 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Hello, >> >> We have changed the backend of the Pharo Association. >> >> https://association.pharo.org >> >> If you ever joined the association in the past, please consider to >> re-subscribe. >> >> We have added already all existing active members, in this case you should >> have already received a new password. >> >> For all questions, do not hesitate to contact assocation(a)pharo.org >> <assocations(a)pharo.org> >> >> >> Marcus >> > > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 11, 2016

Re: [Pharo-dev] OpalEncoderForV3PlusClosures error

by ClÃ©ment Bera

On latest VM from opensmalltalk you can switch to the SistaV1 encoder which solves this problem. On Nov 10, 2016 23:31, "Thierry Goubier" <thierry.goubier(a)gmail.com> wrote: > > > 2016-11-10 17:28 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> Too many statements probably (e.g. a lot of branches). >> > > I suspected that. Many, many loops over arrays of arrays of arrays of > float, no branches. > > Thierry > > >> >> Max >> >> > On 10 Nov 2016, at 17:11, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> > >> > I've got a compilation error which is: >> > >> > genJumpLong: distance index -1504 is out of range -1024 to 1023 >> > >> > What does it mean? I'm on Pharo6 64 bits. >> > >> > Thierry >> >> >> >

Nov. 11, 2016

Re: [Pharo-dev] Please test new VMs (round one)

by HernÃ¡n Morales Durand

No problem, I was asking about instructions to download and reproduce the Windows VM compilation problem. But Esteban already gave me some steps to start. HernÃ¡n 2016-11-10 13:21 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > What is your exact question ? > > > On 10 Nov 2016, at 16:31, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > Anyone? > > > > > > 2016-11-09 14:17 GMT-03:00 HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > > > > > > 2016-11-09 8:00 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi guys, > > > > I want to start moving the VM stuff into the new structure. Now I know > there are still missing things :) > > Can you download a VM from here: https://bintray.com/estebanlm/ > pharo-vm/build/201611082123#files > > > > and start using it, and report problems? > > > > thanks! > > Esteban > > > > ps: Windows users: Iâm still not there, Iâm having problems to build > third-party libraries with cygwinâ¦ also if someone can help me here I would > thank it :) > > > > > > I can help, let me know how can I reproduce those problems > > > > HernÃ¡n > > > > > > >

Nov. 11, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

On 10 November 2016 at 19:58, Stephan Eggermont <stephan(a)stack.nl> wrote: > Igor wrote: > >Now i hope at the end of the day, > >the guys who doing data mining/statistical > >analysis will finally shut up and happily > >be able to work with more bloat without > >need of learning a ways to properly > >manage memory & resources, and > >implement them finally. > > The actual problem is of course having to work with all that data before > you understand the structure. Or highly interconnected structures with > unpredictable access patterns. Partial graphs are nice, once you understand > how to partition. Needing to understand how to partition first is a > dependency I'd rather avoid. > > No, no, no! This is simply not true. It is you, who writes the code that generates a lot of statistical data/analysis data, and its output is fairly predictable.. else you are not collecting any data, but just a random noise, isn't? Those graphs are far from being unpredictable, because they are product of a software you wrote. Its not unpredictable, unless you claim that code you write is unpredictable, then i wonder, what are you doing in a field of data analysis, if you admit that your data is nothing but just a dice roll? If you cannot tame & reason about the complexity of own code, then maybe better to change occupation and go work in casino? :) I mean, Doru is light years ahead of me and many others in field of data analysis.. so what i can advise to him on his playground? You absolutely right, that the most hardest part, you identified, is find the way how you dissect the graph data on smaller chunks. And storing such dissected graph in chunks on a hard drive outside of image and loading in case of need, is just nothing compared to the first part. And if Doru can't handle this, then who else can? Me? I have nothing comparing to his experience in that field. I had very little/occasional experience in my career where i had to deal with such domain. Cmon.. > >Because even if you can fit all data in > >memory, consider how much time it takes > >for GC to scan 4+ Gb of memory, > > That's often not what is happening. The large data is mostly static, so > gets moved out of new space very quickly. Otherwise working with large data > quickly becomes annoying indeed. I fully agree with you on that. > > Stephan > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Stephan Eggermont

Igor wrote: >Now i hope at the end of the day, >the guys who doing data mining/statistical >analysis will finally shut up and happily >be able to work with more bloat without >need of learning a ways to properly >manage memory & resources, and >implement them finally. The actual problem is of course having to work with all that data before you understand the structure. Or highly interconnected structures with unpredictable access patterns. Partial graphs are nice, once you understand how to partition. Needing to understand how to partition first is a dependency I'd rather avoid. >Because even if you can fit all data in >memory, consider how much time it takes >for GC to scan 4+ Gb of memory, That's often not what is happening. The large data is mostly static, so gets moved out of new space very quickly. Otherwise working with large data quickly becomes annoying indeed. I fully agree with you on that. Stephan

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

On 10 November 2016 at 18:57, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > I see you are still having fun :). I am not sure what you are arguing > about, but it does not seem to be much related to what I said. > > It is not fun, seeing that after years since we discussed this problem, and i shared my view on it, nothing changed. I really wish that problem be lifted from your eyesight. But your rhetoric tells me that you prefer to sit and wait instead of solving it. But feel free to tell me, if i am wrong. > And again, I would be very happy to work with you on something concrete. > Just let me know if this is of interest and perhaps we can channel the > energy on solutions rather than on discussions like this. > > Why bother? Lets wait till be will have desktops with 1TB of RAM :) Ohh. sorry. Yeah, unfortunately i don't have much free time right now to dedicate to Pharo. But who knows, it may change. As you can see i keep coming, because smalltalk is not something you can forget after you learned it :) Please, don't take my tone too close. Its my frustration takes offensive forms. My frustration, that i assuming that you can help youself, because your problem is not that hard to solve. But instead, you prefer to rely on somebody else's effort(s). Arrhgghhh!! :) Cheers, > Doru > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

On 10 November 2016 at 18:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 10 Nov 2016, at 17:35, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > > > > The speed of GC will always be in linear dependency from the size of > governed memory. > > > > Asymptotic complexity of GC is O(N), where N is heap size - amount of > objects, not memory size. > > Even that is not necessarily true, Generational Garbage collection and > other tricks can avoid a full heap GC for a long time, even (or especially) > under memory allocation stress. > That's why it asymptotic.. Still more objects => more memory.. O(N) => O(K).. so my statement holds true. And all of the tricks is a puny attempts to workaround that , all those generational, multi-generational, permanent space etc etc. It does helps, of course, but not solves the problem. Since you can always invent a real-world scenario where you can put it on knees and so, that it from 'asymptotic' becomes quite 'symptotic'.. so, all those elaborations does not dismiss my argument, especially when we're talking about large data. When it comes about BIG data - manual data/resource management is the way to go. The rest is handwaving and self-delugion :) > > Apart from that, of course we have to write the most resource efficient > code that we can ! > > > I agree, however, that it's not good to create a lot of short living > objects. That is why there are many practices how to overcome this problem. > For example Object Pool can be nice example. > > > > Nevertheless I can imagine many usecasses when breaking 4GB limit is > useful. For example double buffering during rendering process. 1 pixel > takes 32bit of memory => 8k image (near future displays) would take 126Mb > of memory. Double buffering would be useful for Roassal (huge zoomed out > visualization). > > > > Storing 126Mb array object takes a lot of memory but does not influence > on GC performance since it is just one object on the heap. > > > > Cheers > > Alex > > > > > > On Nov 10, 2016 5:02 PM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > > > > > On 10 November 2016 at 11:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Igor, > > > > I am happy to see you getting active again. The next step is to commit > code at the rate you reply emails. Iâd be even happier :). > > > > To address your point, of course it certainly would be great to have > more people work on automated support for swapping data in and out of the > image. That was the original idea behind the Fuel work. I have seen a > couple of cases on the mailing lists where people are actually using Fuel > for caching purposes. I have done this a couple of times, too. But, at this > point these are dedicated solutions and would be interesting to see it > expand further. > > > > However, your assumption is that the best design is one that deals with > small chunks of data at a time. This made a lot of sense when memory was > expensive and small. But, these days the cost is going down very rapidly, > and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong > signs of super large non-volatile memories become increasingly accessible. > The software design should take advantage of what hardware offers, so it is > not unreasonable to want to have a GC that can deal with large size. > > > > The speed of GC will always be in linear dependency from the size of > governed memory. Yes, yes.. super fast and super clever, made by some > wizard.. but still same dependency. > > So, it will be always in your interest to keep memory footprint as small > as possible. PERIOD. > > > > We should always challenge the assumptions behind our designs, because > the world keeps changing and we risk becoming irrelevant, a syndrome that > is not foreign to Smalltalk aficionados. > > > > > > What you saying is just: okay, we have a problem here, we hit a wall.. > But we don't look for solutions! Instead let us sit and wait till someone > else will be so generous to help with it. > > WOW, what a brilliant strategy!! > > So, you putting fate of your project(s) into hands of 3-rd party, which > > a) maybe , only maybe will work to solve your problem in next 10 years > > b) may decide it not worth effort right now(never) and focus on > something else, because they have own priorities after all > > > > Are you serious? > > "Our furniture don't fits in modern truck(s), so let us wait will > industry invent bigger trucks, build larger roads and then we will move" > Hilarious! > > > > In that case, the problem that you arising is not that mission-critical > to you, and thus making constant noise about your problem(s) is just what > it is: a noise. > > Which returns us to my original mail with offensive tone. > > > > > > Cheers, > > Doru > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Not knowing how to do something is not an argument for how it cannot be > done." > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Aliaksei Syrel

On 10 November 2016 at 17:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Even that is not necessarily true, Generational Garbage collection and > other tricks can avoid a full heap GC for a long time, even (or especially) > under memory allocation stress. That is why it is Big O notation (upper bound / worst case) ;)

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Tudor Girba

Hi Igor, I see you are still having fun :). I am not sure what you are arguing about, but it does not seem to be much related to what I said. And again, I would be very happy to work with you on something concrete. Just let me know if this is of interest and perhaps we can channel the energy on solutions rather than on discussions like this. Cheers, Doru > On Nov 10, 2016, at 5:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 10 November 2016 at 11:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > I am happy to see you getting active again. The next step is to commit code at the rate you reply emails. Iâd be even happier :). > > To address your point, of course it certainly would be great to have more people work on automated support for swapping data in and out of the image. That was the original idea behind the Fuel work. I have seen a couple of cases on the mailing lists where people are actually using Fuel for caching purposes. I have done this a couple of times, too. But, at this point these are dedicated solutions and would be interesting to see it expand further. > > However, your assumption is that the best design is one that deals with small chunks of data at a time. This made a lot of sense when memory was expensive and small. But, these days the cost is going down very rapidly, and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong signs of super large non-volatile memories become increasingly accessible. The software design should take advantage of what hardware offers, so it is not unreasonable to want to have a GC that can deal with large size. > > The speed of GC will always be in linear dependency from the size of governed memory. Yes, yes.. super fast and super clever, made by some wizard.. but still same dependency. > So, it will be always in your interest to keep memory footprint as small as possible. PERIOD. > > We should always challenge the assumptions behind our designs, because the world keeps changing and we risk becoming irrelevant, a syndrome that is not foreign to Smalltalk aficionados. > > > What you saying is just: okay, we have a problem here, we hit a wall.. But we don't look for solutions! Instead let us sit and wait till someone else will be so generous to help with it. > WOW, what a brilliant strategy!! > So, you putting fate of your project(s) into hands of 3-rd party, which > a) maybe , only maybe will work to solve your problem in next 10 years > b) may decide it not worth effort right now(never) and focus on something else, because they have own priorities after all > > Are you serious? > "Our furniture don't fits in modern truck(s), so let us wait will industry invent bigger trucks, build larger roads and then we will move" Hilarious! > > In that case, the problem that you arising is not that mission-critical to you, and thus making constant noise about your problem(s) is just what it is: a noise. > Which returns us to my original mail with offensive tone. > > > Cheers, > Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Nov. 10, 2016