May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Possible Zinc Bug: empty path segments returns nil

by Sven Van Caekenberghe

On 08 May 2014, at 21:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I expected... self assert: 'http://google.com/' asUrl pathSegments isEmpty Well, self deny: 'http://google.com/' asUrl hasPath But I understand the confusion, I'll flag this for my todo/tothink > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Possible-Zinc-Bug-empty-path-segments-returns-nil-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 8, 2014

Re: [Pharo-dev] [Moose-dev] Roassal visualizing a corner of the Universe

by Ronie Salgado

Alex, We need a DSL with the following features: - Lazy evaluation. - Matrix/vector operations - Multiples backends, for fallback if OpenCL is not available in some platform. The trickiest part is the one of Lazy evaluation. This is important, specially because the number of computations required for (AB)C or A(BC) can be orders of magnitude different. Greetings, Ronie 2014-05-08 16:53 GMT-04:00 kilon alios <kilon.alios(a)gmail.com>: > is this project going to be open source, or you will keep it private ? > > > On Thu, May 8, 2014 at 11:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> We have matrices of size 2000 x 2000. Soon we would like to work with >> matrices 2000 x 2000 x 10 000. >> Your work on OpenCL is __highly__ important to us >> >> Alexandre >> >> >> On May 8, 2014, at 4:02 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: >> >> > Alex, >> > >> > What is the size of those matrices? >> > >> > >> > 2014-05-08 15:56 GMT-04:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > My first thought would be to have some particular C routines to perform >> a transformation on a matrix. >> > This would not be that difficult I guess. Well.. We have to see. We >> will likely enter the optimization phase in a couple of months from now. >> > >> > Alexandre >> > >> > >> > On May 8, 2014, at 2:15 PM, Chris Cunningham <cunningham.cb(a)gmail.com> >> wrote: >> > >> > > So, Hannes may have been referring to optimizing the slow parts of >> the process in Native Boost directly instead of using an external library >> (if not, may I suggest it?). It is possible that just a few tweaks using >> Assembler in the process would get the speed up to an acceptable level, >> which would be determined by profiling the performance. Of course, that >> path requires someone on your project that can understand Assembler to get >> familiar with NativeBoost. >> > > -cbc >> > > >> > > On Thu, May 8, 2014 at 8:05 AM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> > > We will surely review all the different options for interacting with >> external libraries. Ronie is our local expert :-) >> > > >> > > Currently, we have no preview of the Roassal book to share. Give us a >> couple of months :-) >> > > >> > > Cheers, >> > > Alexandre >> > > >> > > >> > > On May 8, 2014, at 9:23 AM, H. Hirzel <hannes.hirzel(a)gmail.com> >> wrote: >> > > >> > > > Interesting project, Alexandre! >> > > > >> > > > On 5/6/14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> > > >> Thanks Kilon for your nice words. >> > > >> Currently, AstroCloud is a bit slow. For example, loading this >> image takes >> > > >> much more than it should. For now, speed is not our priority. >> AstroCloud has >> > > >> to be fast and we will make it fast. Probably relying on external >> library is >> > > >> the way to go. >> > > > >> > > > I assume you consider or have considered NativeBoost as well? >> > > > >> > > >> >> > > >> Just to give a bit more context about why we are doing AstroCloud. >> ALMA is >> > > >> the largest observatory on Earth, making it the largest >> astronomical project >> > > >> in existence (http://www.almaobservatory.org) This is what >> humanity has >> > > >> best to detect life outside Earth. >> > > >> ALMA is made of 66 high-precision antenas making it possible to >> see deep in >> > > >> the universe. Unfortunately, there is no good software to process >> these >> > > >> immensely complex pictures. Some tool suite naturally exist, but >> they were >> > > >> not made for ALMA, making these existing tools largely suboptimal >> to process >> > > >> complex picture of ALMA. >> > > >> Faviolaâs dream (and mine) is to produce a tool ready to be >> consumed by >> > > >> astronomers to process ALMA pictures. Faviola and I are currently >> seeking >> > > >> for additional resources on making this happen. >> > > > >> > > > >> > > >> Regarding your help about documenting Roassal. It is very welcome! >> In one of >> > > >> my previous post, I said that 2014 will be the year of documenting >> Roassal. >> > > >> A book is on its way. >> > > > >> > > > >> > > >> We will need people to review it. So thanks! >> > > > >> > > > Preview of part of it on line? >> > > > >> > > > >> > > > Regards >> > > > Hannes >> > > > >> > > > _______________________________________________ >> > > > Moose-dev mailing list >> > > > Moose-dev(a)iam.unibe.ch >> > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > >> > > -- >> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > > Alexandre Bergel http://www.bergel.eu >> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > >> > > >> > > >> > > >> > > >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >

May 8, 2014

Re: [Pharo-dev] Starting making bindings for OpenCL using NativeBoost.

by Ronie Salgado

> > Blender <http://www.blender.org/> is actually porting OpenCL for its > rendering engine cycles. Cycles already uses CUDA. They say that OpenCL is > quite buggy yet and not well supported. Whats your experience with it ? This is actually a problem with the AMD implementation of OpenCL, and yes it is buggy, but being improved over the time, specially after Valve is going for Linux and the new generation of consoles is based in AMD hardware. Until AMD made the GCN architecture(HD7xxx and upward), they did not have hardware support for function calls unlike NVIDIA, so they have to inline everything. The Blender Cycles rendering engine is huge, and specially their noise functions used for procedural textures. Because everything was being in-lined, they ended running out of memory easily when compiling their kernels for the first time. In my desktop machine with 3 GB of RAM I end without of memory when trying Cycles with OpenCL, but in my laptop with 8 GB of RAM it works, but not perfect because they haven't done(at least the last year when I last tried ) too much testing with OpenCL. With GCN AMD should have fixed the problem, but they keep using the same intermediate representation that they used for their previouse generation, so they keep inlining everything. In some time AMD should fix the problem, specially when most of the new generation of consoles uses GCN and Valve coming to Linux. My recommendation is to keep OpenCL kernels as simple as possible, which should also be done for performance. Are you going to expose also an API for non graphic stuff ? > I am exposing some parts of the OpenCL API one by one. OpenCL is a small API, but it is designed for C, so I am trying to make it a bit more Smalltalk friendlier. But just a bit more. For testing the bindings, I have one test that performs a simple big vector addition. So, it can be used for non graphics stuffs. Graphics are cooler to show. do you think that we could have a openCL back-end for athens? > Yes, it should be possible. A scanline renderer in OpenCL should be really interesting of implementing. But, I think that a better option is to use OpenGL with the Stencil Buffer and manual evaluation of the curves. I have done it before for vector graphics, and I need an OpenGL based Athens backend for Roassal 3D and my next video-game graphics engine. I also tried some time ago with the paper present here: http://ramisantina.com/blog/2011/09/resolution-independent-curves-at-graphi…. I am interested in extending his technique from quadratic NURBS into cubic NURBS. They are lot of different ways for making 2D vector graphics in the GPU, and I want to try some of them for profiling. do you think that we could avoid having openCL text inside Pharo but have a > kind of DSL? > I hate MATLAB, so I would love a DSL for working with matrices, vectors and use Roassal/GraphET for displaying the data and plotting. This should be very easy to implement. For some domains, making a DSL should be easy. In general, a DSL for the GPGPU is not going to be enough. Some algorithms have to be adapted explicitly for the GPU, taking in account the presence of different memory models, such as the local memory. If we want a generic model, we need to make a different Pharo-ish programming language. The work with UFFI/VirtualCPU should make that very long term task easy. But for now, lets just use some DSLs. Greetings, Ronie 2014-05-08 11:06 GMT-04:00 stepharo <stepharo(a)free.fr>: > Hi ronie > > Some questions: > do you think that we could have a openCL back-end for athens? > > do you think that we could avoid having openCL text inside Pharo but > have a kind of DSL? > > Stef > > > On 8/5/14 08:32, Ronie Salgado wrote: > >> Hello, >> >> I started working in making some basic bindings for OpenCL using >> NativeBoost. >> >> Currently I can run basics OpenCL OpenCL kernels. I tried to generate >> quickly some procedural images which was a success. >> >> I am going to be showing some more cool stuffs when mixing >> OpenCL+OpenGL+SDL2. >> >> Currently uploading my work into http://smalltalkhub.com/#!/~ >> ronsaldo/OpenCL <http://smalltalkhub.com/#%21/%7Eronsaldo/OpenCL> . No >> configuration or stable release yet. >> >> Greetings, >> Ronie >> > > >

May 8, 2014

Re: [Pharo-dev] [Moose-dev] Roassal visualizing a corner of the Universe

by kilon alios

is this project going to be open source, or you will keep it private ? On Thu, May 8, 2014 at 11:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > We have matrices of size 2000 x 2000. Soon we would like to work with > matrices 2000 x 2000 x 10 000. > Your work on OpenCL is __highly__ important to us > > Alexandre > > > On May 8, 2014, at 4:02 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > > Alex, > > > > What is the size of those matrices? > > > > > > 2014-05-08 15:56 GMT-04:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > My first thought would be to have some particular C routines to perform > a transformation on a matrix. > > This would not be that difficult I guess. Well.. We have to see. We will > likely enter the optimization phase in a couple of months from now. > > > > Alexandre > > > > > > On May 8, 2014, at 2:15 PM, Chris Cunningham <cunningham.cb(a)gmail.com> > wrote: > > > > > So, Hannes may have been referring to optimizing the slow parts of the > process in Native Boost directly instead of using an external library (if > not, may I suggest it?). It is possible that just a few tweaks using > Assembler in the process would get the speed up to an acceptable level, > which would be determined by profiling the performance. Of course, that > path requires someone on your project that can understand Assembler to get > familiar with NativeBoost. > > > -cbc > > > > > > On Thu, May 8, 2014 at 8:05 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > > We will surely review all the different options for interacting with > external libraries. Ronie is our local expert :-) > > > > > > Currently, we have no preview of the Roassal book to share. Give us a > couple of months :-) > > > > > > Cheers, > > > Alexandre > > > > > > > > > On May 8, 2014, at 9:23 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > > > > > Interesting project, Alexandre! > > > > > > > > On 5/6/14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > >> Thanks Kilon for your nice words. > > > >> Currently, AstroCloud is a bit slow. For example, loading this > image takes > > > >> much more than it should. For now, speed is not our priority. > AstroCloud has > > > >> to be fast and we will make it fast. Probably relying on external > library is > > > >> the way to go. > > > > > > > > I assume you consider or have considered NativeBoost as well? > > > > > > > >> > > > >> Just to give a bit more context about why we are doing AstroCloud. > ALMA is > > > >> the largest observatory on Earth, making it the largest > astronomical project > > > >> in existence (http://www.almaobservatory.org) This is what > humanity has > > > >> best to detect life outside Earth. > > > >> ALMA is made of 66 high-precision antenas making it possible to see > deep in > > > >> the universe. Unfortunately, there is no good software to process > these > > > >> immensely complex pictures. Some tool suite naturally exist, but > they were > > > >> not made for ALMA, making these existing tools largely suboptimal > to process > > > >> complex picture of ALMA. > > > >> Faviolaâs dream (and mine) is to produce a tool ready to be > consumed by > > > >> astronomers to process ALMA pictures. Faviola and I are currently > seeking > > > >> for additional resources on making this happen. > > > > > > > > > > > >> Regarding your help about documenting Roassal. It is very welcome! > In one of > > > >> my previous post, I said that 2014 will be the year of documenting > Roassal. > > > >> A book is on its way. > > > > > > > > > > > >> We will need people to review it. So thanks! > > > > > > > > Preview of part of it on line? > > > > > > > > > > > > Regards > > > > Hannes > > > > > > > > _______________________________________________ > > > > Moose-dev mailing list > > > > Moose-dev(a)iam.unibe.ch > > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

May 8, 2014

Re: [Pharo-dev] WTF and Programming Languages

by kilon alios

looks I created quite an interesting discussion :) Glad you guys enjoyed and got inspired by the video. I amwatching your replies with interest. On Thu, May 8, 2014 at 10:55 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > > Le 8 mai 2014 18:30, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > > > > > Sven Van Caekenberghe-2 wrote > > > The why is the result not 'Helloworld' ? or 'Hellworldo' ? Why does > the $o > > > appear twice ? > > > > Good point. > > > > Please take a moment to: > > 1. go to Ulysses > > 2. follow the account creation link > > 3. create an account on fogbugz > > 4. log in > > 5. create an issue report with: > > a. the vm version > > b. the image version > > c. your platform > > d. your social security number > > e. mother's maiden name > > f. name of first pet > > g. and, a reproducible way to cause the error > > 6. (optional, but preferable) followed up by a slice with tests > > a. re-log-in to fogbugz > > b. go back to the issue page because the fogbugz login page probably > > didn't redirect you to the issue > > c. add whoever is assigned as another person to notify because they > will > > paradoxically not be included by default > > 7. (if 6) add class comments to classes that you didn't modify - and > > possibly have never heard of - to make the monkey happy > > 8. Weigh in on whether Pharo is or is not "Smalltalk" AND/OR whether a > > tomato is a fruit or a vegetable > > 9. Cross fingers and wait (but not as long as in Squeak) > > 10. Try to remember what you were doing before you fell down the rabbit > hole > > 11. Check email for VPRI's final STEPS report while waiting > > > > IN CASE OF EMERGENCY: insert beer between or during any other step OR > > remember that we (meaning the Smalltalk, Smalltalk-inspired, > > Smalltalk-channelled, Smalltalk-related, and/or Dynabook-related > identified > > persons and possibly spouses and probably children under 17.5) still > have it > > far better than the rest of the programming world > > > > ;-P (hopefully obviously) > > > > WAT? > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/WTF-and-Programming-Languages-tp4758263p4758348.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > >

May 8, 2014

Re: [Pharo-dev] [Moose-dev] Roassal visualizing a corner of the Universe

by Alexandre Bergel

We have matrices of size 2000 x 2000. Soon we would like to work with matrices 2000 x 2000 x 10 000. Your work on OpenCL is __highly__ important to us Alexandre On May 8, 2014, at 4:02 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Alex, > > What is the size of those matrices? > > > 2014-05-08 15:56 GMT-04:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > My first thought would be to have some particular C routines to perform a transformation on a matrix. > This would not be that difficult I guess. Well.. We have to see. We will likely enter the optimization phase in a couple of months from now. > > Alexandre > > > On May 8, 2014, at 2:15 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > > So, Hannes may have been referring to optimizing the slow parts of the process in Native Boost directly instead of using an external library (if not, may I suggest it?). It is possible that just a few tweaks using Assembler in the process would get the speed up to an acceptable level, which would be determined by profiling the performance. Of course, that path requires someone on your project that can understand Assembler to get familiar with NativeBoost. > > -cbc > > > > On Thu, May 8, 2014 at 8:05 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > We will surely review all the different options for interacting with external libraries. Ronie is our local expert :-) > > > > Currently, we have no preview of the Roassal book to share. Give us a couple of months :-) > > > > Cheers, > > Alexandre > > > > > > On May 8, 2014, at 9:23 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > > > Interesting project, Alexandre! > > > > > > On 5/6/14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > >> Thanks Kilon for your nice words. > > >> Currently, AstroCloud is a bit slow. For example, loading this image takes > > >> much more than it should. For now, speed is not our priority. AstroCloud has > > >> to be fast and we will make it fast. Probably relying on external library is > > >> the way to go. > > > > > > I assume you consider or have considered NativeBoost as well? > > > > > >> > > >> Just to give a bit more context about why we are doing AstroCloud. ALMA is > > >> the largest observatory on Earth, making it the largest astronomical project > > >> in existence (http://www.almaobservatory.org) This is what humanity has > > >> best to detect life outside Earth. > > >> ALMA is made of 66 high-precision antenas making it possible to see deep in > > >> the universe. Unfortunately, there is no good software to process these > > >> immensely complex pictures. Some tool suite naturally exist, but they were > > >> not made for ALMA, making these existing tools largely suboptimal to process > > >> complex picture of ALMA. > > >> Faviolaâs dream (and mine) is to produce a tool ready to be consumed by > > >> astronomers to process ALMA pictures. Faviola and I are currently seeking > > >> for additional resources on making this happen. > > > > > > > > >> Regarding your help about documenting Roassal. It is very welcome! In one of > > >> my previous post, I said that 2014 will be the year of documenting Roassal. > > >> A book is on its way. > > > > > > > > >> We will need people to review it. So thanks! > > > > > > Preview of part of it on line? > > > > > > > > > Regards > > > Hannes > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)iam.unibe.ch > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2014

Re: [Pharo-dev] [Moose-dev] Roassal visualizing a corner of the Universe

by Ronie Salgado

Alex, What is the size of those matrices? 2014-05-08 15:56 GMT-04:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > My first thought would be to have some particular C routines to perform a > transformation on a matrix. > This would not be that difficult I guess. Well.. We have to see. We will > likely enter the optimization phase in a couple of months from now. > > Alexandre > > > On May 8, 2014, at 2:15 PM, Chris Cunningham <cunningham.cb(a)gmail.com> > wrote: > > > So, Hannes may have been referring to optimizing the slow parts of the > process in Native Boost directly instead of using an external library (if > not, may I suggest it?). It is possible that just a few tweaks using > Assembler in the process would get the speed up to an acceptable level, > which would be determined by profiling the performance. Of course, that > path requires someone on your project that can understand Assembler to get > familiar with NativeBoost. > > -cbc > > > > On Thu, May 8, 2014 at 8:05 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > We will surely review all the different options for interacting with > external libraries. Ronie is our local expert :-) > > > > Currently, we have no preview of the Roassal book to share. Give us a > couple of months :-) > > > > Cheers, > > Alexandre > > > > > > On May 8, 2014, at 9:23 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > > > Interesting project, Alexandre! > > > > > > On 5/6/14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > >> Thanks Kilon for your nice words. > > >> Currently, AstroCloud is a bit slow. For example, loading this image > takes > > >> much more than it should. For now, speed is not our priority. > AstroCloud has > > >> to be fast and we will make it fast. Probably relying on external > library is > > >> the way to go. > > > > > > I assume you consider or have considered NativeBoost as well? > > > > > >> > > >> Just to give a bit more context about why we are doing AstroCloud. > ALMA is > > >> the largest observatory on Earth, making it the largest astronomical > project > > >> in existence (http://www.almaobservatory.org) This is what humanity > has > > >> best to detect life outside Earth. > > >> ALMA is made of 66 high-precision antenas making it possible to see > deep in > > >> the universe. Unfortunately, there is no good software to process > these > > >> immensely complex pictures. Some tool suite naturally exist, but they > were > > >> not made for ALMA, making these existing tools largely suboptimal to > process > > >> complex picture of ALMA. > > >> Faviolaâs dream (and mine) is to produce a tool ready to be consumed > by > > >> astronomers to process ALMA pictures. Faviola and I are currently > seeking > > >> for additional resources on making this happen. > > > > > > > > >> Regarding your help about documenting Roassal. It is very welcome! In > one of > > >> my previous post, I said that 2014 will be the year of documenting > Roassal. > > >> A book is on its way. > > > > > > > > >> We will need people to review it. So thanks! > > > > > > Preview of part of it on line? > > > > > > > > > Regards > > > Hannes > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)iam.unibe.ch > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

May 8, 2014

Re: [Pharo-dev] [Moose-dev] Roassal visualizing a corner of the Universe

by Alexandre Bergel

My first thought would be to have some particular C routines to perform a transformation on a matrix. This would not be that difficult I guess. Well.. We have to see. We will likely enter the optimization phase in a couple of months from now. Alexandre On May 8, 2014, at 2:15 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > So, Hannes may have been referring to optimizing the slow parts of the process in Native Boost directly instead of using an external library (if not, may I suggest it?). It is possible that just a few tweaks using Assembler in the process would get the speed up to an acceptable level, which would be determined by profiling the performance. Of course, that path requires someone on your project that can understand Assembler to get familiar with NativeBoost. > -cbc > > On Thu, May 8, 2014 at 8:05 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > We will surely review all the different options for interacting with external libraries. Ronie is our local expert :-) > > Currently, we have no preview of the Roassal book to share. Give us a couple of months :-) > > Cheers, > Alexandre > > > On May 8, 2014, at 9:23 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > Interesting project, Alexandre! > > > > On 5/6/14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Thanks Kilon for your nice words. > >> Currently, AstroCloud is a bit slow. For example, loading this image takes > >> much more than it should. For now, speed is not our priority. AstroCloud has > >> to be fast and we will make it fast. Probably relying on external library is > >> the way to go. > > > > I assume you consider or have considered NativeBoost as well? > > > >> > >> Just to give a bit more context about why we are doing AstroCloud. ALMA is > >> the largest observatory on Earth, making it the largest astronomical project > >> in existence (http://www.almaobservatory.org) This is what humanity has > >> best to detect life outside Earth. > >> ALMA is made of 66 high-precision antenas making it possible to see deep in > >> the universe. Unfortunately, there is no good software to process these > >> immensely complex pictures. Some tool suite naturally exist, but they were > >> not made for ALMA, making these existing tools largely suboptimal to process > >> complex picture of ALMA. > >> Faviolaâs dream (and mine) is to produce a tool ready to be consumed by > >> astronomers to process ALMA pictures. Faviola and I are currently seeking > >> for additional resources on making this happen. > > > > > >> Regarding your help about documenting Roassal. It is very welcome! In one of > >> my previous post, I said that 2014 will be the year of documenting Roassal. > >> A book is on its way. > > > > > >> We will need people to review it. So thanks! > > > > Preview of part of it on line? > > > > > > Regards > > Hannes > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2014

Re: [Pharo-dev] WTF and Programming Languages

by phil＠highoctane.be

Le 8 mai 2014 18:30, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > > Sven Van Caekenberghe-2 wrote > > The why is the result not 'Helloworld' ? or 'Hellworldo' ? Why does the $o > > appear twice ? > > Good point. > > Please take a moment to: > 1. go to Ulysses > 2. follow the account creation link > 3. create an account on fogbugz > 4. log in > 5. create an issue report with: > a. the vm version > b. the image version > c. your platform > d. your social security number > e. mother's maiden name > f. name of first pet > g. and, a reproducible way to cause the error > 6. (optional, but preferable) followed up by a slice with tests > a. re-log-in to fogbugz > b. go back to the issue page because the fogbugz login page probably > didn't redirect you to the issue > c. add whoever is assigned as another person to notify because they will > paradoxically not be included by default > 7. (if 6) add class comments to classes that you didn't modify - and > possibly have never heard of - to make the monkey happy > 8. Weigh in on whether Pharo is or is not "Smalltalk" AND/OR whether a > tomato is a fruit or a vegetable > 9. Cross fingers and wait (but not as long as in Squeak) > 10. Try to remember what you were doing before you fell down the rabbit hole > 11. Check email for VPRI's final STEPS report while waiting > > IN CASE OF EMERGENCY: insert beer between or during any other step OR > remember that we (meaning the Smalltalk, Smalltalk-inspired, > Smalltalk-channelled, Smalltalk-related, and/or Dynabook-related identified > persons and possibly spouses and probably children under 17.5) still have it > far better than the rest of the programming world > > ;-P (hopefully obviously) > WAT? > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/WTF-and-Programming-Languages-tp4758263p4758348.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 8, 2014

Re: [Pharo-dev] Verifying Ubuntu downloads

by Damien Cassou

On Thu, May 8, 2014 at 7:46 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Did it finally work or did you get tired of beta testing? ;) ok, I've just tried. This instruction NBMacShell run: 'md5 "', self fullName, '" > "', tmpFile fullName, '"'. returns 32512 and does not write anything in tmpFile. I'm on Linux and I'm not sure NBMacShell is supposed to work there. Moreover, #secureUrl is sent on instance side but only implemented on class side. Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 8, 2014