June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Pharo-2.0-Tests Â» 32,mac - Build # 108 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 2, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 108 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by StÃ©phane Ducasse

On Jun 2, 2012, at 5:52 PM, Igor Stasenko wrote: > On 2 June 2012 17:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Don't you think that this is what we are trying to do since ages: improving the infrastructure >> but not by piling junk on junk. > > hehe stef.. I can say this happens everywhere. Piles of junk on top of > each other.. still my point is valid. How can we move on at the VM level by step by step improving it How can we make sure that the code of david from 2006 which speeds up directories will be integrated? How can we reduce the complexity of the vm? This is why I'm working on the consortium to get a chance to the community. Stef > > Like figuring out, why output of readdir() function having strange results.. > To figure it out, you have to read this code, and understand what's going on: > this is part of standard C library on mac (/usr/include/dirent.h on > your machine, you can check it) > > > __BEGIN_DECLS > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int alphasort(const void *, const void *) __DARWIN_INODE64(alphasort); > #endif /* not POSIX */ > int closedir(DIR *) __DARWIN_ALIAS(closedir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int getdirentries(int, char *, int, long *) > #if __DARWIN_64_BIT_INO_T > /* > * getdirentries() doesn't work when 64-bit inodes is in effect, so we > * generate a link error. > */ > __asm("_getdirentries_is_not_available_when_64_bit_inodes_are_in_effect") > #else /* !__DARWIN_64_BIT_INO_T */ > __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0,__MAC_10_6, > __IPHONE_2_0,__IPHONE_2_0) > #endif /* __DARWIN_64_BIT_INO_T */ > ; > #endif /* not POSIX */ > DIR *opendir(const char *) __DARWIN_ALIAS_I(opendir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > DIR *__opendir2(const char *, int) __DARWIN_ALIAS_I(__opendir2); > #endif /* not POSIX */ > struct dirent *readdir(DIR *) __DARWIN_INODE64(readdir); > int readdir_r(DIR *, struct dirent *, struct dirent **) > __DARWIN_INODE64(readdir_r); > void rewinddir(DIR *) __DARWIN_ALIAS_I(rewinddir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int scandir(const char *, struct dirent ***, > int (*)(struct dirent *), int (*)(const void *, const void *)) > __DARWIN_INODE64(scandir); > #ifdef __BLOCKS__ > int scandir_b(const char *, struct dirent ***, > int (^)(struct dirent *), int (^)(const void *, const void *)) > __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, > __IPHONE_3_2); > #endif /* __BLOCKS__ */ > #endif /* not POSIX */ > void seekdir(DIR *, long) __DARWIN_ALIAS_I(seekdir); > long telldir(DIR *) __DARWIN_ALIAS_I(telldir); > __END_DECLS > > #endif /* !KERNEL */ > > > > > > -- > Best regards, > Igor Stasenko. >

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Nicolas Cellier

2012/6/2 Igor Stasenko <siguctua(a)gmail.com>: > You know, Sean, what i like about C that every time i entering C > domain i need to > solve yet another hard to crack puzzle which takes unpredictably big > amount of time. > And you can never be sure that there is no hidden surprises behind next turn.. > something which conceptually trivial to implement and even can fit on > one blank of paper > in C code, could take days before you can make it working. > > Because C programming practices strictly following WYSIWYDG principle > (What You See Is What You DONT Get). > I would say, that you MIGHT get, depending on compiler and options... > So, every time you feel like you lack of confusing moments during your day, > just go to /usr/include directory, open any header and try to read it ... :) > > Or if you prefer C++, best is to read STL library code, or Boost Â code. > +1, one of my favourite argument against C++ I always wondered which part of such obfuscation was intentional (vs necessary) C++ adds complexity for sure, some totally useless like distinction between delete and delete[], since underneath you still have dumb pointers, and the compiler can't make a distinction, it's just one more responsibility for the programmer. Nicolas > On 2 June 2012 17:51, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> StÃ©phane Ducasse wrote >>> >>> To me it just shows that there is no concerted momentum around VMs... >>> Probably Pythoners and ruby people are more concerned. >>> >> >> Yes. Probably they are concerned because they are so much slower than us ;) >> http://shootout.alioth.debian.org/u32/performance.php?test=meteor >> >> Don't get discouraged. The VM is frightening and mysterious to many, but >> with the help of Igor, Mariano, and others around to write blogs, answer >> questions, improve the build process, and lead the charge to improve, it >> seems that working on the VM is becoming more and more accessible/common... >> Even last year at ESUG, with 1 year using Smalltalk, I found building and >> working on the VM frustrating and confusing. But now, esp. with >> Jenkins/git/etc, it's a snap, for example, to build debug VMs, step through >> execution, and even submit VM patches. >> >> Let's keep our great energy and progress multiplying... >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/NB-FileSystem-Primitives-Speedup-tp4632820p4632911.ht… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. >

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Nicolas Cellier

2012/6/2 Igor Stasenko <siguctua(a)gmail.com>: > On 2 June 2012 17:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Don't you think that this is what we are trying to do since ages: improving the infrastructure >> but not by piling junk on junk. > > hehe stef.. I can say this happens everywhere. Piles of junk on top of > each other.. > > Like figuring out, why output of readdir() function having strange results.. > To figure it out, you have to read this code, and understand what's going on: > Â this is part of standard C library on mac (/usr/include/dirent.h on > your machine, you can check it) > > > __BEGIN_DECLS > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int alphasort(const void *, const void *) __DARWIN_INODE64(alphasort); > #endif /* not POSIX */ > int closedir(DIR *) __DARWIN_ALIAS(closedir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int getdirentries(int, char *, int, long *) > #if __DARWIN_64_BIT_INO_T > /* > Â * getdirentries() doesn't work when 64-bit inodes is in effect, so we > Â * generate a link error. > Â */ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â __asm("_getdirentries_is_not_available_when_64_bit_inodes_are_in_effect") > #else /* !__DARWIN_64_BIT_INO_T */ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0,__MAC_10_6, > __IPHONE_2_0,__IPHONE_2_0) > #endif /* __DARWIN_64_BIT_INO_T */ > ; > #endif /* not POSIX */ > DIR *opendir(const char *) __DARWIN_ALIAS_I(opendir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > DIR *__opendir2(const char *, int) __DARWIN_ALIAS_I(__opendir2); > #endif /* not POSIX */ > struct dirent *readdir(DIR *) __DARWIN_INODE64(readdir); > int readdir_r(DIR *, struct dirent *, struct dirent **) > __DARWIN_INODE64(readdir_r); > void rewinddir(DIR *) __DARWIN_ALIAS_I(rewinddir); > #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) > int scandir(const char *, struct dirent ***, > Â Â int (*)(struct dirent *), int (*)(const void *, const void *)) > __DARWIN_INODE64(scandir); > #ifdef __BLOCKS__ > int scandir_b(const char *, struct dirent ***, > Â Â int (^)(struct dirent *), int (^)(const void *, const void *)) > __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, > __IPHONE_3_2); > #endif /* __BLOCKS__ */ > #endif /* not POSIX */ > void seekdir(DIR *, long) __DARWIN_ALIAS_I(seekdir); > long telldir(DIR *) __DARWIN_ALIAS_I(telldir); > __END_DECLS > > #endif /* !KERNEL */ > Ouch, Igor, you gonna give us a headache. That's exatly the kind of niceties that makes FFI impracticle without a pre-processor, remember our discussion? Nicolas

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

You know, Sean, what i like about C that every time i entering C domain i need to solve yet another hard to crack puzzle which takes unpredictably big amount of time. And you can never be sure that there is no hidden surprises behind next turn.. something which conceptually trivial to implement and even can fit on one blank of paper in C code, could take days before you can make it working. Because C programming practices strictly following WYSIWYDG principle (What You See Is What You DONT Get). So, every time you feel like you lack of confusing moments during your day, just go to /usr/include directory, open any header and try to read it ... :) Or if you prefer C++, best is to read STL library code, or Boost code. On 2 June 2012 17:51, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > StÃ©phane Ducasse wrote >> >> To me it just shows that there is no concerted momentum around VMs... >> Probably Pythoners and ruby people are more concerned. >> > > Yes. Probably they are concerned because they are so much slower than us ;) > http://shootout.alioth.debian.org/u32/performance.php?test=meteor > > Don't get discouraged. The VM is frightening and mysterious to many, but > with the help of Igor, Mariano, and others around to write blogs, answer > questions, improve the build process, and lead the charge to improve, it > seems that working on the VM is becoming more and more accessible/common... > Even last year at ESUG, with 1 year using Smalltalk, I found building and > working on the VM frustrating and confusing. But now, esp. with > Jenkins/git/etc, it's a snap, for example, to build debug VMs, step through > execution, and even submit VM patches. > > Let's keep our great energy and progress multiplying... > > Sean > > -- > View this message in context: http://forum.world.st/NB-FileSystem-Primitives-Speedup-tp4632820p4632911.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

On 2 June 2012 17:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Don't you think that this is what we are trying to do since ages: improving the infrastructure > but not by piling junk on junk. hehe stef.. I can say this happens everywhere. Piles of junk on top of each other.. Like figuring out, why output of readdir() function having strange results.. To figure it out, you have to read this code, and understand what's going on: this is part of standard C library on mac (/usr/include/dirent.h on your machine, you can check it) __BEGIN_DECLS #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) int alphasort(const void *, const void *) __DARWIN_INODE64(alphasort); #endif /* not POSIX */ int closedir(DIR *) __DARWIN_ALIAS(closedir); #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) int getdirentries(int, char *, int, long *) #if __DARWIN_64_BIT_INO_T /* * getdirentries() doesn't work when 64-bit inodes is in effect, so we * generate a link error. */ __asm("_getdirentries_is_not_available_when_64_bit_inodes_are_in_effect") #else /* !__DARWIN_64_BIT_INO_T */ __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0,__MAC_10_6, __IPHONE_2_0,__IPHONE_2_0) #endif /* __DARWIN_64_BIT_INO_T */ ; #endif /* not POSIX */ DIR *opendir(const char *) __DARWIN_ALIAS_I(opendir); #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) DIR *__opendir2(const char *, int) __DARWIN_ALIAS_I(__opendir2); #endif /* not POSIX */ struct dirent *readdir(DIR *) __DARWIN_INODE64(readdir); int readdir_r(DIR *, struct dirent *, struct dirent **) __DARWIN_INODE64(readdir_r); void rewinddir(DIR *) __DARWIN_ALIAS_I(rewinddir); #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) int scandir(const char *, struct dirent ***, int (*)(struct dirent *), int (*)(const void *, const void *)) __DARWIN_INODE64(scandir); #ifdef __BLOCKS__ int scandir_b(const char *, struct dirent ***, int (^)(struct dirent *), int (^)(const void *, const void *)) __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2); #endif /* __BLOCKS__ */ #endif /* not POSIX */ void seekdir(DIR *, long) __DARWIN_ALIAS_I(seekdir); long telldir(DIR *) __DARWIN_ALIAS_I(telldir); __END_DECLS #endif /* !KERNEL */ -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > To me it just shows that there is no concerted momentum around VMs... > Probably Pythoners and ruby people are more concerned. > Yes. Probably they are concerned because they are so much slower than us ;) http://shootout.alioth.debian.org/u32/performance.php?test=meteor Don't get discouraged. The VM is frightening and mysterious to many, but with the help of Igor, Mariano, and others around to write blogs, answer questions, improve the build process, and lead the charge to improve, it seems that working on the VM is becoming more and more accessible/common... Even last year at ESUG, with 1 year using Smalltalk, I found building and working on the VM frustrating and confusing. But now, esp. with Jenkins/git/etc, it's a snap, for example, to build debug VMs, step through execution, and even submit VM patches. Let's keep our great energy and progress multiplying... Sean -- View this message in context: http://forum.world.st/NB-FileSystem-Primitives-Speedup-tp4632820p4632911.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

On 2 June 2012 17:01, David T. Lewis <lewis(a)mail.msen.com> wrote: > > <OT> > IMHO more people need to learn how to write small plugins. It is important > for modularity and reliability, and for trying new VM experiments without > waiting for a "VM guru" to help. Maybe you can also provide a way for > people to add their experimental plugins to the Jenkins builds too, so > that they can be made quickly available to anyone with an interest. > </OT> > > Dave yes, i would wellcome that. And if you know, for instance we got this lately: https://ci.lille.inria.fr/pharo/view/Cog/job/CogDroid/ but sometimes i feel like crying it the desert. 1. There's not many people who can be attracted in hacking VM(s) 2. And even among those who can, not many feel excited about idea of improving and reimplementing it The principle "don't fix it if it not broken" works pretty well in VM domain , because of factor of 10 in having fun & time spent when hacking smalltalk code vs hacking VM code. -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by StÃ©phane Ducasse

> > That is easy to explain ... I was lazy and did not bother to maintain it ;) I do not buy such easy excuse. This is not your fault. It means that nobody cares. > As for process, it is simple. Just build the plugin (though it probably > will need maintenance for bit rot), and add it to your VM builds. On > the image side, add the support to use the plugin if present, else fall > back on old methods. So like that bugs will just be more difficult to track? I like the idea everybody doing its own little hack in his corner. Sounds like software engineering but not with the right definition to me. > I like small plugins because they are modular and reliable. They can > be added and removed without a lot of coordination with VM builders, > platform maintainers, etc. On the image side, you can easily detect > if the plugin is present, so it is not necessary to worry so much > about what version of VM or FilePlugin is running. This was the same shitty story as having a slow socketStream in the image and that everybody had to load the FastSocketStream. Hopefully an idiot like me or marcus renamed FastSocketStream into SocketStream and did not say it and suddenly we got a decent socket stream. Else we would all have again a bad one. > So the answer is ... Just Do It :) Don't you think that this is what we are trying to do since ages: improving the infrastructure but not by piling junk on junk. David we are talking about File operations not funky experimental stuff. To me it just shows that there is no concerted momentum around VMs. Now people will shoot at me but I do not care just immensely sad. When I imagine that I'm spending my time trying to make sure that companies can built software around Smalltalk. Sometimes I think that I'm in the wrong community. Probably Pythoners and ruby people are more concerned. > <OT> > IMHO more people need to learn how to write small plugins. It is important > for modularity and reliability, and for trying new VM experiments without > waiting for a "VM guru" to help. Maybe you can also provide a way for > people to add their experimental plugins to the Jenkins builds too, so > that they can be made quickly available to anyone with an interest. > </OT> You mean with an svn structure where guys like igor do not have commit rights? Probably but this is difficult and not really welcoming. Stef > > Dave > >

June 2, 2012