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

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Esteban Lorenzano

and btw, Igor doesn't drink, but I can take the beer for the two ;) On Oct 19, 2012, at 10:20 PM, Craig Latta <craig(a)netjam.org> wrote: > > Success! 3 + 4 = 7! Thanks! > > I'll buy you a beer the next time I see you, for sure. :) > > I wimped out and installed gcc 4.2 before I built, so I can't > report on any LLVM issues. > > As for the howto document, perhaps split it into two documents? One > for jenkins, one for gitorious. That would be better suited to reading > in a hurry. > > > thanks again! > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 (no SMS) > >

Oct. 19, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Esteban Lorenzano

cool! :) On Oct 19, 2012, at 10:20 PM, Craig Latta <craig(a)netjam.org> wrote: > > Success! 3 + 4 = 7! Thanks! > > I'll buy you a beer the next time I see you, for sure. :) > > I wimped out and installed gcc 4.2 before I built, so I can't > report on any LLVM issues. > > As for the howto document, perhaps split it into two documents? One > for jenkins, one for gitorious. That would be better suited to reading > in a hurry. > > > thanks again! > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 (no SMS) > >

Oct. 19, 2012

Re: [Pharo-project] Smart chars behavior

by StÃ©phane Ducasse

> > > ws contents: '|foo'' > type: $' > expected: ''|foo'' > current: '''|foo'' and then usually I have to remove the fucking extra ' that the system just blindly added :( Stef

Oct. 19, 2012

Re: [Pharo-project] building the VM

by Craig Latta

Hi Igor-- > [Igor refers to my first attempt with the gitorious approach.] > > Craig, that probably a sign that you using wrong version of > CMakeVMMaker package not one which is used for the sources committed > in git. Oh, okay, that's disturbing since I was going from the Metacello configuration Mariano suggested. > For that there is codegen-scripts/LoadVMMaker.st script which > loads exact version of all packages used to build VM. > We usually don't commit code without changing LoadVMMaker.st, and > making sure it builds VM with that version. Aha, okay. > for developers, best is , of course > do > git clone > instead of > git clone --depth=0 > > for non-developers, just download tarball from jenkins , > change the paths in build/directories.cmake to your local ones > and just build. (and you don't need an image in that case) > > (btw, i wonder, why we need that feature (to use arbitrary paths for > sources/platform/build directories), > if nobody using it.. which prevents us from having relative paths in > directories.cmake file, > like that people can build downloaded sources without any changes). Yeah, I would think a main feature of having a buildable snapshot is that people can just grab it and build it without having to configure anything. thanks again, -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 19, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Craig Latta

Success! 3 + 4 = 7! Thanks! I'll buy you a beer the next time I see you, for sure. :) I wimped out and installed gcc 4.2 before I built, so I can't report on any LLVM issues. As for the howto document, perhaps split it into two documents? One for jenkins, one for gitorious. That would be better suited to reading in a hurry. thanks again! -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Dale Henrichs

Igor, I think we can agree that readability is subjective, beyond that I'm afraid that we aren't going to see eye to eye. Put us in the same room with a whiteboard and we might be able to understand each other's perspective if not come to see eye to eye. Separated by thousands of miles...the best we can hope for is to agree to disagree. Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, October 19, 2012 12:43:33 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 18:47, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Igor, | > | > "But my aims is slightly different." and so are mine ... | > | > I think that we can agree on this point and move on... | > | :) | | i cannot agree on one point: JSON is harder to read to me, comparing | to smalltalk literal syntax. | This is a reason for dismissing 'human friendliness' comparison, | because it is very subjective :) | | But what i want to repeat: uniformity has the value. | When users, to read code, need to know single language, it is better | than need to know 2 , 3 or more. | So, unless there is no way to express meta (and other) information | using same language, only then i won't argue why we need to use | different language for information we store. | A good example where you cannot do that is C projects, which contain | makefiles, config files , and other. | | Out of curiosity, can you read this (exert from configure script): | | as_fn_mkdir_p () | { | | case $as_dir in #( | -*) as_dir=./$as_dir;; | esac | test -d "$as_dir" || eval $as_mkdir_p || { | as_dirs= | while :; do | case $as_dir in #( | *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; | #'( | *) as_qdir=$as_dir;; | esac | as_dirs="'$as_qdir' $as_dirs" | as_dir=`$as_dirname -- "$as_dir" || | $as_expr X"$as_dir" : 'X$.*[^/]$//*[^/][^/]*/*$' \| \ | X"$as_dir" : 'X$//$[^/]' \| \ | X"$as_dir" : 'X$//$$' \| \ | X"$as_dir" : 'X$/$' \| . 2>/dev/null || | $as_echo X"$as_dir" | | sed '/^X$.*[^/]$\/\/*[^/][^/]*\/*$/{ | s//\1/ | q | } | /^X$\/\/$[^/].*/{ | s//\1/ | q | } | /^X$\/\/$$/{ | s//\1/ | q | } | /^X$\/$.*/{ | s//\1/ | q | } | | ..... | | as to me if we take negative infinity , and then raise it to power of | positive infinity, | then it will be close to "human readability" of this code. | | But C guys have no choice: they cannot express metainformation in C.. | (or just too lazy).. | But with smalltalk, we can. So why we need to use weird syntax, and | weird DSLs, if we can just keep using smalltalk, and benefit | (greatly) | from uniformity and simplicity it has? | Remember the turtles? They have to go all the way down :) | | -- | Best regards, | Igor Stasenko. | |

Oct. 19, 2012

Re: [Pharo-project] Mariano's VM-building instructions don't seem to work

by Igor Stasenko

for developers, best is , of course do git clone instead of git clone --depth=0 for non-developers, just download tarball from jenkins , change the paths in build/directories.cmake to your local ones and just build. (and you don't need an image in that case) (btw, i wonder, why we need that feature (to use arbitrary paths for sources/platform/build directories), if nobody using it.. which prevents us from having relative paths in directories.cmake file, like that people can build downloaded sources without any changes). -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Igor Stasenko

cmake . make is not longer valid. on mac one should use: cmake . make make install. or just use 'build.sh' script which autogenerated by image (in build directory). i added it, because i also forgetting that last step time to time (since the changes i did lately requires 'make install' step). On 19 October 2012 20:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > mmm... > > VMBuilder buildFromScratch. > > would be even cooler ;) > > ah, dreams... but we will get there... eventually. > > Esteban > > ps: Craig, I'm really interested on you succeed on building vm, please, keep me in track :) > > On Oct 19, 2012, at 8:50 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2012-10-19, at 20:42, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> >>> On 2012-10-19, at 20:39, Craig Latta <craig(a)netjam.org> wrote: >>> >>>> >>>>> (RE)CREATING THE GENERATED VM SOURCES >>>>> ===================================== >>>>> >>>>> If you downloaded the sources from gitorious do the following the VM >>>>> sources are not included (unlike the jenkins build download). The >>>>> following steps explain how to generate the VM sources from a build >>>>> image. >>>> >>>> Also, in this subthread with you I was trying to get your suggested >>>> jenkins solution to work, not the "download from gitorious" one. >>>> HOWTOBUILD says in the jenkins case I should just be able to "cd build; >>>> cmake; make". >> >> I'm off for tonight, let me know if it worked. I would really love to >> see a proper HOWTOBUILD instruction text, that works from scratch ;) >> >> cami >> > > -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by StÃ©phane Ducasse

Camillo tell me where I can start and I will debug the process. I'm excellent I finding stuff that do not work :) Stef >>>> (RE)CREATING THE GENERATED VM SOURCES >>>> ===================================== >>>> >>>> If you downloaded the sources from gitorious do the following the VM >>>> sources are not included (unlike the jenkins build download). The >>>> following steps explain how to generate the VM sources from a build >>>> image. >>> >>> Also, in this subthread with you I was trying to get your suggested >>> jenkins solution to work, not the "download from gitorious" one. >>> HOWTOBUILD says in the jenkins case I should just be able to "cd build; >>> cmake; make". > > I'm off for tonight, let me know if it worked. I would really love to > see a proper HOWTOBUILD instruction text, that works from scratch ;) > > cami >

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 19 October 2012 18:47, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > "But my aims is slightly different." and so are mine ... > > I think that we can agree on this point and move on... > :) i cannot agree on one point: JSON is harder to read to me, comparing to smalltalk literal syntax. This is a reason for dismissing 'human friendliness' comparison, because it is very subjective :) But what i want to repeat: uniformity has the value. When users, to read code, need to know single language, it is better than need to know 2 , 3 or more. So, unless there is no way to express meta (and other) information using same language, only then i won't argue why we need to use different language for information we store. A good example where you cannot do that is C projects, which contain makefiles, config files , and other. Out of curiosity, can you read this (exert from configure script): as_fn_mkdir_p () { case $as_dir in #( -*) as_dir=./$as_dir;; esac test -d "$as_dir" || eval $as_mkdir_p || { as_dirs= while :; do case $as_dir in #( *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; #'( *) as_qdir=$as_dir;; esac as_dirs="'$as_qdir' $as_dirs" as_dir=`$as_dirname -- "$as_dir" || $as_expr X"$as_dir" : 'X$.*[^/]$//*[^/][^/]*/*$' \| \ X"$as_dir" : 'X$//$[^/]' \| \ X"$as_dir" : 'X$//$$' \| \ X"$as_dir" : 'X$/$' \| . 2>/dev/null || $as_echo X"$as_dir" | sed '/^X$.*[^/]$\/\/*[^/][^/]*\/*$/{ s//\1/ q } /^X$\/\/$[^/].*/{ s//\1/ q } /^X$\/\/$$/{ s//\1/ q } /^X$\/$.*/{ s//\1/ q } ..... as to me if we take negative infinity , and then raise it to power of positive infinity, then it will be close to "human readability" of this code. But C guys have no choice: they cannot express metainformation in C.. (or just too lazy).. But with smalltalk, we can. So why we need to use weird syntax, and weird DSLs, if we can just keep using smalltalk, and benefit (greatly) from uniformity and simplicity it has? Remember the turtles? They have to go all the way down :) -- Best regards, Igor Stasenko.

Oct. 19, 2012