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

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by Luc Fabresse

2014-11-30 20:51 GMT+01:00 stepharo <stepharo(a)free.fr>: > great now I can compile :) > cool! > About your question about moving > > PharoWebStack should be renamed PharoWeb: a Tutorial > > EntreprisePharo should be renamed PharoWebStack > ok > But I do not know how to do that on github. > I do not know Luc > Stef > > Le 29/11/14 23:22, Luc Fabresse a Ã©crit : > > > now I can compile. > I've pushed some fixes on github, we will see if it now breaks for other > ;-) > > @Stef: > $ luatex -v > This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) (rev > 4971) > > do a macport update if you do not have this version. > $ sudo port selfupdate > $ sudo port update outdated > > Then, you should be able to compile the latest version on github. > > Cheers, > > #Luc > > 2014-11-29 9:23 GMT+01:00 Luc Fabresse <luc.fabresse(a)gmail.com>: > >> >> can one of you just give me the result of: >> >> luatex -v >> >> that works compiling the chapter. >> then, I will investigate. >> >> #Luc >> >> 2014-11-29 8:55 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> The problem is not related to that. >>> To display the full encoding the guys here (damien * damien) only found >>> luaTex working. >>> But LuaTex does not work well on our machines apparently. >>> >>> Le 29/11/14 02:38, Ben Coman a Ã©crit : >>> >>> kilon alios wrote: >>>> >>>>> have you tried MacTex ? >>>>> >>>>> https://tug.org/mactex/ >>>>> >>>>> its what I use with my iMac and so far has been working for me without >>>>> any issues. >>>>> >>>> >>>> I also ended up using MaxTex fairly easily. (I can't remember which >>>> other one originally tried that had some issues.) >>>> cheers -ben >>>> >>>> >>>>> On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse <luc.fabresse(a)gmail.com >>>>> <mailto:luc.fabresse@gmail.com>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I cannot compile the latest version in >>>>> SquareBracketAssociates/EnterprisePharo.git >>>>> My problem is that the "FiraSans" cannot be found. >>>>> But in common.tex, the font path is correctly set up and the font >>>>> is >>>>> there. >>>>> >>>>> So on CI which version of luatex is used? >>>>> I did not find it in the Jenkins log. >>>>> >>>>> I am using LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts >>>>> 2014_1) (rev 4971) >>>>> >>>>> Cheers, >>>>> >>>>> #Luc >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > >

Nov. 30, 2014

Re: [Pharo-dev] New Cog VMs available

by Tudor Girba

+1 Doru On Sun, Nov 30, 2014 at 8:57 PM, stepharo <stepharo(a)free.fr> wrote: > No problem! Thanks for creating this great asset! > > Stef > > > > On Fri, Nov 21, 2014 at 4:08 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3144. >> >> Apologies; the 3143 VMs were broken. >> > > and I'm sorry to say the 3144 look broken too. I suspect the VM is not > correctly normalizing bit-operations on large integers into SmallIntegers > as expected. > > >> CogVM binaries as per VMMaker.oscog-eem.950/r3144 >> >> Fix regression in new primitiveBitShift. >> Introduce >>> as an explicitly signed shift. >> 64-bit ize magnitude64BitIntegerFor:neg:, >> positive64BitIntegerFor: & signed64BitIntegerFor: >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 30, 2014

Re: [Pharo-dev] New Cog VMs available

by stepharo

No problem! Thanks for creating this great asset! Stef > > > On Fri, Nov 21, 2014 at 4:08 PM, Eliot Miranda > <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3144 > <http://www.mirandabanda.org/files/Cog/VM/VM.r3144>. > > Apologies; the 3143 VMs were broken. > > > and I'm sorry to say the 3144 look broken too. I suspect the VM is > not correctly normalizing bit-operations on large integers into > SmallIntegers as expected. > > > CogVM binaries as per VMMaker.oscog-eem.950/r3144 > > Fix regression in new primitiveBitShift. > Introduce >>> as an explicitly signed shift. > 64-bit ize magnitude64BitIntegerFor:neg:, > positive64BitIntegerFor: & signed64BitIntegerFor: > -- > best, > Eliot > > > > > -- > best, > Eliot

Nov. 30, 2014

Re: [Pharo-dev] merge conflict (issue validator)

by stepharo

I do not know either and I hate the reclassification because after it drops from our radar. Le 29/11/14 23:04, Nicolai Hess a Ã©crit : > I don't understand this merge conflict in hte issue validation for > case 14288 <https://pharo.fogbugz.com/default.asp?14288> > I can manually load the slice and it does not show any conflicts. > > Any ideas? > >

Nov. 30, 2014

Re: [Pharo-dev] ensure: and assignments RB Rule

by stepharo

thanks we should open a bug entry to improve the class comment of this rule. Any taker? Stef Le 30/11/14 12:10, Thierry Goubier a Ã©crit : > Le 30/11/2014 12:01, Max Leske a Ã©crit : >> >>> On 30.11.2014, at 11:18, Thierry Goubier <thierry.goubier(a)gmail.com> >>> wrote: >>> >>> Le 30/11/2014 11:06, Max Leske a Ã©crit : >>>> The code would look like this: >>>> >>>> [ | file | >>>> file := StandardFileStream forceNewFileNamed: âfooâ. >>>> file nextPutAll: âbarâ ] >>>> ensure: [ file close ]. >>>> >>>> Why that is considered bad practice however, I canât tell. >>> >>> This one would fail because file is a temp to the block (and not >>> visible to the ensure block). >> >> If it werenât visible, wouldnât the compiler raise an exception? > > In your example, yes. > > But the rule matched: > > | file | > [ > file := StandardFileStream forceNewFileNamed: âfooâ. > file nextPutAll: âbarâ ] > ensure: [ file close ]. > > (Hum: wouldn't the compiler complain of file might be nil in the > ensure block?) > >>> Another problem is that, if you have a failure in >>> forceNewFileNamed:, file is nil and the ensure: fail as well. >> >> True, but thatâs a problem this rule doesnât really cover I guess. >> That oneâs up to the developer. > > I would expect that rule to flag bad coding practices, and I think it > does ;) > > Thierry > >

Nov. 30, 2014

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by stepharo

great now I can compile :) About your question about moving PharoWebStack should be renamed PharoWeb: a Tutorial EntreprisePharo should be renamed PharoWebStack But I do not know how to do that on github. Stef Le 29/11/14 23:22, Luc Fabresse a Ã©crit : > > now I can compile. > I've pushed some fixes on github, we will see if it now breaks for > other ;-) > > @Stef: > $ luatex -v > This is LuaTeX, Version beta-0.79.1 (TeX Live 2014/MacPorts 2014_3) > (rev 4971) > > do a macport update if you do not have this version. > $ sudo port selfupdate > $ sudo port update outdated > > Then, you should be able to compile the latest version on github. > > Cheers, > > #Luc > > 2014-11-29 9:23 GMT+01:00 Luc Fabresse <luc.fabresse(a)gmail.com > <mailto:luc.fabresse@gmail.com>>: > > > can one of you just give me the result of: > > luatex -v > > that works compiling the chapter. > then, I will investigate. > > #Luc > > 2014-11-29 8:55 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > The problem is not related to that. > To display the full encoding the guys here (damien * damien) > only found luaTex working. > But LuaTex does not work well on our machines apparently. > > Le 29/11/14 02:38, Ben Coman a Ã©crit : > > kilon alios wrote: > > have you tried MacTex ? > > https://tug.org/mactex/ > > its what I use with my iMac and so far has been > working for me without any issues. > > > I also ended up using MaxTex fairly easily. (I can't > remember which other one originally tried that had some > issues.) > cheers -ben > > > On Sat, Nov 29, 2014 at 12:02 AM, Luc Fabresse > <luc.fabresse(a)gmail.com > <mailto:luc.fabresse@gmail.com> > <mailto:luc.fabresse@gmail.com > <mailto:luc.fabresse@gmail.com>>> wrote: > > Hi All, > > I cannot compile the latest version in > SquareBracketAssociates/EnterprisePharo.git > My problem is that the "FiraSans" cannot be found. > But in common.tex, the font path is correctly set > up and the font is > there. > > So on CI which version of luatex is used? > I did not find it in the Jenkins log. > > I am using LuaTeX, Version beta-0.79.1 (TeX Live > 2014/MacPorts > 2014_1) (rev 4971) > > Cheers, > > #Luc > > > > > > > > >

Nov. 30, 2014

Re: [Pharo-dev] Compilation error of the PharoEnterprise book with luatex

by stepharo

his is LuaTeX, Version beta-0.79.1 (TeX Live 2014) (rev 4971) Execute 'luatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. Copyright 2014 Taco Hoekwater, the LuaTeX Team. Le 29/11/14 09:23, Luc Fabresse a Ã©crit : > luatex -v

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by stepharo

Tx dale. Yes it was like that :) Le 30/11/14 16:58, Dale Henrichs a Ã©crit : > Actually, SS3 and smalltalkhub appeared about the same time. Tobias > Pape had been slowly improving the GemStone version of SqueakSource3 > and I got tired of waiting 2-3 days for SqueakSource to come back from > a crash, so I pushed SS3 up as an Alpha to get something up that was > more stable than SqueakSource. About the same time, SmalltalkHub was > made available and I didn't want to compete with SmalltalkHub and at > the time it seemed to have potential, so I backed off on my plans to > go beyond the Alpha release of SS3. There were several sets of known > bugs and performance issues ... but it was and still is Alpha and was > never intended to go into production. > > After several months of development, SmalltalkHub had not quite made > it to be production ready and Stef asked me to start backing up SS3 so > that it could be used for production apps ... I reluctantly agreed, > because at the time SqueakSource was very unstable and something was > needed ... > > Unfortunately the time window for me to have time to devote time to > SS3 had passed and Tobias was busy with his work as well. > > And it took longer than originally anticipated for SmalltalkHub to be > ready for prime time. > > Tobias has continued to work on the SqueakSource3 code base and bring > it way beyond the Alpha version that is in production. The folks at > Hasso Plattner Institute are using Tobias' SqueakSource3 in > production for their Smalltalk repos. > > But it seemed to not be worth the effort to try to compete with > SmalltalkHub ... the original intent of SS3 being brought into > production was to be a stopgap measure until SmalltalkHub was ready... > > Today, I am using GitHub for all of my projects ([1], [2], [3], and > [4]) so again I just don't have the time to devote to SS3 to > incorporate the improvements that Tobias has had (for years now) .... > > Neither SqueakSource3 nor SmalltalkHub comes close to the > collaborative feature set of GitHub and I personally would rather > devote my own time and effort to new Smalltalk projects than trying to > duplicate GitHub in Smalltalk. > > We continue to host SS3, with all of its Alpha warts because is very > stable and a number of folks use it on a daily basis... > > Dale > > [1] https://github.com/GsDevKit > [2] https://github.com/glassdb > [3] https://github.com/dalehenrich > [4] https://github.com/CampSmalltalk > > On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > btwâ¦ historic reference: sthub was never intended to be there > for stay. I remember talking about it with Nico and Stef, > more than two years ago, before sthub came online, and our > conclusion at the time was: âyes, the future it will be git, > but until we get there, letâs put sthub online because > sqsource cannot handle more projects" > > > And why you not choose squeaksource3 which maintained by gemstone > team and includes all features from old squeaksource? Why you > instead develop sthub if you not believe in it? > > >

Nov. 30, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by stepharo

+1 It was like that. > >> On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk(a)gmail.com >> <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>>: >> >> btwâ¦ historic reference: sthub was never intended to be there for >> stay. I remember talking about it with Nico and Stef, more than >> two years ago, before sthub came online, and our conclusion at >> the time was: âyes, the future it will be git, but until we get >> there, letâs put sthub online because sqsource cannot handle more >> projects" >> >> >> And why you not choose squeaksource3 which maintained by gemstone >> team and includes all features from old squeaksource? Why you instead >> develop sthub if you not believe in it? > > Smalltalkhub was already there. > Question was if we put it online or not, not if we develop it or not. > ss3 was there but Dale always said (at the time) that was a proof of > concept and that having time for work on it was complicated (and > search was severely broken, and it was slow and we were having *real* > problems when doing massive downloads). > both situations are probably fixed now, but at the time having a 3rd > solution for the community looked like a good idea. > > and I believe it was. Even if you plan, in the future, to provide > something else that you believe is better, when you are developing > something like Pharo you have certain responsibilities with your > community, you cannot drop something without having already a good > replacement. We needed a solution soon, we had sthub, so it was a good > match. > and look nowâ¦ I still believe the future is using Git as our central > source management system, but we are still not there, tools are still > not good enough and then, we still need to have tools like sthub. > > Esteban > > >> >> >

Nov. 30, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Dale Henrichs

Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:) Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Dale, > > On Nov 30, 2014, at 8:14 AM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > > > > On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> So far all I knew that using git for binary files was a no go, doable >> but not recommended. Thus I found strange that filetree uses binary files. >> >> > Well the files are text files, but because the text represents structured > data, the line-based auto-merge used by git is not correct ... > > The monticello version files have been included in FileTree to make it > possible to move the packages seamlessly between Filetree-based > repositories and mcz based repositories ... without that meta data, once > you move a package to FileTree it could not be moved back into an mcz > repository without losing all of the package history. > > When I was first introducing FileTree, I thought it was important that > folks be able to test out the git waters without making an "irreversible > commitment to git." Even today I find myself needing to move packages back > and forth between git and mcz repositories, so Thierry's merge-tools has > made it possible for me to have my cake and eat it too. > > I have been threatening to remove the monticello meta data from FileTree > (or at least make it optional), but I just haven't had the time or > motivation to do so ... again Thierry's merge-tool means that I never have > to deal with a manual merge of the version file, so for me I never have to > think about it ... > > As the tool sets for supporting git improve and as the community begins to > use git-based repos as their primary repository, it will make sense to > remove the monticello meta data from FileTree ... > > > Will that mean that packages will still be able to be interchanged with > Monticello? If yes, will that mean that packages will still be able to > be merged with Monticello? > > Dale > >

Nov. 30, 2014