July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] GitFileTree Warning on Pharo 5

by Thierry Goubier

Le 27 juil. 2015 10:03 PM, "Dimitris Chloupis" <kilon.alios(a)gmail.com> a Ã©crit : > > maybe add it to stable and update config in the pharo 5 meta repo so we can all get it through conf browser ? I'll do that. I'm camping at the moment, so I'm not supposed to do Pharo coding ;) Thierry > > On Mon, Jul 27, 2015 at 10:58 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> This has been fixed some time ago, but is still in dev branch, so #loadDevelopment should do the trick. >> >> Peter >> >> On Mon, Jul 27, 2015 at 9:50 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>> >>> I try to install GitFileTree on Pharo and I get this warning >>> >>> This package depends on the following classes: StringHolder You must resolve these dependencies before you will be able to load these definitions: CrLfFileEditor CrLfFileEditor>>#defaultLineEndConvention CrLfFileEditor>>#editFileNamed: CrLfFileEditor>>#fileNamed: CrLfFileEditor>>#fileNamed:inDirectoryPath: CrLfFileEditor>>#fileNamed:withLabel: CrLfFileEditor>>#initialize CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName: CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName:lineEndConvention: CrLfFileEditor>>#openForFileNamed: CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName: CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName:lineEndConvention: CrLfFileEditor>>#windowColorSpecification CrLfFileEditor>>#bogusTruncate: CrLfFileEditor>>#browseChanges CrLfFileEditor>>#contents CrLfFileEditor>>#contents: CrLfFileEditor>>#controllerForAccept CrLfFileEditor>>#currentFilePathName CrLfFileEditor>>#defaultFont CrLfFileEditor>>#directory: CrLfFileEditor>>#exit CrLfFileEditor>>#fileContentsMenu:shifted: CrLfFileEditor>>#fileName: CrLfFileEditor>>#forceDirtyBuffer CrLfFileEditor>>#getAnotherFileName: CrLfFileEditor>>#getFileName: CrLfFileEditor>>#getHex CrLfFileEditor>>#getSelection CrLfFileEditor>>#getText CrLfFileEditor>>#hexFormat: CrLfFileEditor>>#labelString CrLfFileEditor>>#lineEndConvention: CrLfFileEditor>>#mvcWithLabel: CrLfFileEditor>>#openAsMorphLabel: CrLfFileEditor>>#openLabel: CrLfFileEditor>>#put: CrLfFileEditor>>#save CrLfFileEditor>>#saveAs CrLfFileEditor>>#selectedClassOrMetaClass CrLfFileEditor>>#selectedMessageCategoryName CrLfFileEditor>>#updateFilePathWith: CrLfFileEditor>>#viewStyle: CrLfFileEditor>>#withLabel: Select Proceed to continue, or close this window to cancel the operation. >>> >>> Should I be worried ? Will this mess up my git repo ? >> >>

July 27, 2015

Re: [Pharo-users] Markdown -> Pillar

by HernÃ¡n Morales Durand

Thanks Damien, HernÃ¡n 2015-07-27 5:52 GMT-03:00 Damien Cassou <damien.cassou(a)inria.fr>: > > HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> writes: > > > Has anyone implemented a feature to convert a document from Markdown > format > > to Pillar? > > not yet. But Jan implemented a full-featured Markdown parser in > PetitParser so I guess the hard part has been written already. I know > others are interested in that too, e.g., Norbert. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

July 27, 2015

Re: [Pharo-users] GitFileTree Warning on Pharo 5

by Dimitris Chloupis

maybe add it to stable and update config in the pharo 5 meta repo so we can all get it through conf browser ? On Mon, Jul 27, 2015 at 10:58 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > This has been fixed some time ago, but is still in dev branch, so > #loadDevelopment should do the trick. > > Peter > > On Mon, Jul 27, 2015 at 9:50 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> I try to install GitFileTree on Pharo and I get this warning >> >> This package depends on the following classes: StringHolder You must >> resolve these dependencies before you will be able to load these >> definitions: CrLfFileEditor CrLfFileEditor>>#defaultLineEndConvention >> CrLfFileEditor>>#editFileNamed: CrLfFileEditor>>#fileNamed: >> CrLfFileEditor>>#fileNamed:inDirectoryPath: >> CrLfFileEditor>>#fileNamed:withLabel: CrLfFileEditor>>#initialize >> CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName: >> CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName:lineEndConvention: >> CrLfFileEditor>>#openForFileNamed: >> CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName: >> CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName:lineEndConvention: >> CrLfFileEditor>>#windowColorSpecification CrLfFileEditor>>#bogusTruncate: >> CrLfFileEditor>>#browseChanges CrLfFileEditor>>#contents >> CrLfFileEditor>>#contents: CrLfFileEditor>>#controllerForAccept >> CrLfFileEditor>>#currentFilePathName CrLfFileEditor>>#defaultFont >> CrLfFileEditor>>#directory: CrLfFileEditor>>#exit >> CrLfFileEditor>>#fileContentsMenu:shifted: CrLfFileEditor>>#fileName: >> CrLfFileEditor>>#forceDirtyBuffer CrLfFileEditor>>#getAnotherFileName: >> CrLfFileEditor>>#getFileName: CrLfFileEditor>>#getHex >> CrLfFileEditor>>#getSelection CrLfFileEditor>>#getText >> CrLfFileEditor>>#hexFormat: CrLfFileEditor>>#labelString >> CrLfFileEditor>>#lineEndConvention: CrLfFileEditor>>#mvcWithLabel: >> CrLfFileEditor>>#openAsMorphLabel: CrLfFileEditor>>#openLabel: >> CrLfFileEditor>>#put: CrLfFileEditor>>#save CrLfFileEditor>>#saveAs >> CrLfFileEditor>>#selectedClassOrMetaClass >> CrLfFileEditor>>#selectedMessageCategoryName >> CrLfFileEditor>>#updateFilePathWith: CrLfFileEditor>>#viewStyle: >> CrLfFileEditor>>#withLabel: Select Proceed to continue, or close this >> window to cancel the operation. >> >> Should I be worried ? Will this mess up my git repo ? >> > >

July 27, 2015

Re: [Pharo-users] GitFileTree Warning on Pharo 5

by Peter UhnÃ¡k

This has been fixed some time ago, but is still in dev branch, so #loadDevelopment should do the trick. Peter On Mon, Jul 27, 2015 at 9:50 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I try to install GitFileTree on Pharo and I get this warning > > This package depends on the following classes: StringHolder You must > resolve these dependencies before you will be able to load these > definitions: CrLfFileEditor CrLfFileEditor>>#defaultLineEndConvention > CrLfFileEditor>>#editFileNamed: CrLfFileEditor>>#fileNamed: > CrLfFileEditor>>#fileNamed:inDirectoryPath: > CrLfFileEditor>>#fileNamed:withLabel: CrLfFileEditor>>#initialize > CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName: > CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName:lineEndConvention: > CrLfFileEditor>>#openForFileNamed: > CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName: > CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName:lineEndConvention: > CrLfFileEditor>>#windowColorSpecification CrLfFileEditor>>#bogusTruncate: > CrLfFileEditor>>#browseChanges CrLfFileEditor>>#contents > CrLfFileEditor>>#contents: CrLfFileEditor>>#controllerForAccept > CrLfFileEditor>>#currentFilePathName CrLfFileEditor>>#defaultFont > CrLfFileEditor>>#directory: CrLfFileEditor>>#exit > CrLfFileEditor>>#fileContentsMenu:shifted: CrLfFileEditor>>#fileName: > CrLfFileEditor>>#forceDirtyBuffer CrLfFileEditor>>#getAnotherFileName: > CrLfFileEditor>>#getFileName: CrLfFileEditor>>#getHex > CrLfFileEditor>>#getSelection CrLfFileEditor>>#getText > CrLfFileEditor>>#hexFormat: CrLfFileEditor>>#labelString > CrLfFileEditor>>#lineEndConvention: CrLfFileEditor>>#mvcWithLabel: > CrLfFileEditor>>#openAsMorphLabel: CrLfFileEditor>>#openLabel: > CrLfFileEditor>>#put: CrLfFileEditor>>#save CrLfFileEditor>>#saveAs > CrLfFileEditor>>#selectedClassOrMetaClass > CrLfFileEditor>>#selectedMessageCategoryName > CrLfFileEditor>>#updateFilePathWith: CrLfFileEditor>>#viewStyle: > CrLfFileEditor>>#withLabel: Select Proceed to continue, or close this > window to cancel the operation. > > Should I be worried ? Will this mess up my git repo ? >

July 27, 2015

GitFileTree Warning on Pharo 5

by Dimitris Chloupis

I try to install GitFileTree on Pharo and I get this warning This package depends on the following classes: StringHolder You must resolve these dependencies before you will be able to load these definitions: CrLfFileEditor CrLfFileEditor>>#defaultLineEndConvention CrLfFileEditor>>#editFileNamed: CrLfFileEditor>>#fileNamed: CrLfFileEditor>>#fileNamed:inDirectoryPath: CrLfFileEditor>>#fileNamed:withLabel: CrLfFileEditor>>#initialize CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName: CrLfFileEditor>>#on:withLabel:inDirectory:defaultFileName:lineEndConvention: CrLfFileEditor>>#openForFileNamed: CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName: CrLfFileEditor>>#openOn:withLabel:inDirectory:defaultFileName:lineEndConvention: CrLfFileEditor>>#windowColorSpecification CrLfFileEditor>>#bogusTruncate: CrLfFileEditor>>#browseChanges CrLfFileEditor>>#contents CrLfFileEditor>>#contents: CrLfFileEditor>>#controllerForAccept CrLfFileEditor>>#currentFilePathName CrLfFileEditor>>#defaultFont CrLfFileEditor>>#directory: CrLfFileEditor>>#exit CrLfFileEditor>>#fileContentsMenu:shifted: CrLfFileEditor>>#fileName: CrLfFileEditor>>#forceDirtyBuffer CrLfFileEditor>>#getAnotherFileName: CrLfFileEditor>>#getFileName: CrLfFileEditor>>#getHex CrLfFileEditor>>#getSelection CrLfFileEditor>>#getText CrLfFileEditor>>#hexFormat: CrLfFileEditor>>#labelString CrLfFileEditor>>#lineEndConvention: CrLfFileEditor>>#mvcWithLabel: CrLfFileEditor>>#openAsMorphLabel: CrLfFileEditor>>#openLabel: CrLfFileEditor>>#put: CrLfFileEditor>>#save CrLfFileEditor>>#saveAs CrLfFileEditor>>#selectedClassOrMetaClass CrLfFileEditor>>#selectedMessageCategoryName CrLfFileEditor>>#updateFilePathWith: CrLfFileEditor>>#viewStyle: CrLfFileEditor>>#withLabel: Select Proceed to continue, or close this window to cancel the operation. Should I be worried ? Will this mess up my git repo ?

July 27, 2015

SmaCC Warning on Pharo 5

by Dimitris Chloupis

I am installing my project Ephestos on Pharo 5 that depends on SmaCC and SmaCC gives me the following warning This package depends on the following classes: StringHolder You must resolve these dependencies before you will be able to load these definitions: SmaCCCodeHolder SmaCCCodeHolder>>#owner: SmaCCCodeHolder>>#owner:ownerAcceptSelector: SmaCCCodeHolder>>#contents:notifying: SmaCCCodeHolder>>#contentsMenu:shifted: SmaCCCodeHolder>>#contentsMorph SmaCCCodeHolder>>#hasUnacceptedEdits SmaCCCodeHolder>>#okToChange SmaCCCodeHolder>>#owner SmaCCCodeHolder>>#owner: SmaCCCodeHolder>>#owner:ownerAcceptSelector: SmaCCCodeHolder>>#ownerAcceptSelector SmaCCCodeHolder>>#ownerAcceptSelector: SmaCCCodeHolder>>#perform:orSendTo: SmaCCCodeHolder>>#readContentsFromFile SmaCCCodeHolder>>#saveContentsInFile Select Proceed to continue, or close this window to cancel the operation. Is this normal ? Should I be worried ? Is SmaCC ok on Pharo 5 ? Clicking proceed does not appear to create any side effect.

July 27, 2015

Re: [Pharo-users] Separate compilation with Pillar?

by Alexandre Bergel

> Alex you should use the texmate plugin because the chapter is rendered on Cmd-R. Oh! I did not know this! By the way, is there a way to have the spell checker when using TextMate? I do not have the spell checker when editing Pillar files. Am I the only one? Cheers, Alexandre

July 27, 2015

Re: [Pharo-users] Linux Install -- problems, but eventually successful

by Sean P. DeNigris

Andy Jones wrote > since the instructions at > http://pharo.org/gnu-linux-installation#64-bit-System-Setup seem to be out > of date... > Note that there is no ia32-libs package on Jessie, as far as I can tell. The instructions, under "Ubuntu 14.04 and Later", link to http://pharo.org/gnu-linux-installation#ubuntu-ppa-headless-vm , which advises: sudo add-apt-repository ppa:pharo/stable sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install pharo-vm-core Did you try that? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Linux-Install-problems-but-eventually-successful-tp48… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 27, 2015

Re: [Pharo-users] NativeBoost and variadic functions

by Ben Coman

On Mon, Jul 27, 2015 at 9:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> >>> And let me remind you that despite that NB implements FFI to speak with >>> C, it is not obliged to implement features of C language itself. It lets >>> you speak with C programs, but not lets you write programs like in C (see >>> the difference? :) >> >> I wasn't implying that implicit type conversion was a good thing that >> needed implementing -- but just a bump if it hadn't needed attention >> to it before when C did it automagically. >> cheers -ben > > > Of course, Ben, i understand that you may miss some of the feature(s), you > get used to when doing things in C. Sorry I wasn't clear so just to emphasise, I agree NB should not implement such a feature. I was trying to say just that it should be explicit** that implicit type conversions are not supported. A lot of programmers at various levels of experience not very aware of implicit type conversions will probably be bitten by the same error. So to avoid the bites, I guess we need to teach this bit of C when teaching NB. ** perhaps with an example demonstrating it, but I don't know what that might be. cheers -ben > But then consider what is involved to implement such feature because it > means determining argument types at run time (at compile time it is > impossible as well as 'compile once when it is invoked for the first time' > that NB does ) > That means that no matter how well you try, the implementation will suck.. > because it will be very slow comparing to one that uses fixed-type > fixed-argument number. > > My philosophy , in general, for programming is avoid bloat and inefficiency > at all costs. When some feature requires bloat and going to be very > inefficient, i simply saying 'No'. > Especially at infrastructural level, which NB belongs to. > Because one thing that you (of me) as implementer knows what is fast & cool > and what is slow & inefficient, but then users come and start using things > in a way you would never think your stuff will be ever used.. and start > spreading inefficiency in their project(s). And more that that, once they > get used to it, then you would be never able to remove it because it is > there and everyone using it and some even loving it :) > > > -- > Best regards, > Igor Stasenko.

July 27, 2015

Re: [Pharo-users] NativeBoost and variadic functions

by Igor Stasenko

> > > > And let me remind you that despite that NB implements FFI to speak with > C, > > it is not obliged to implement features of C language itself. It lets you > > speak with C programs, but not lets you write programs like in C (see the > > difference? :) > > I wasn't implying that implicit type conversion was a good thing that > needed implementing -- but just a bump if it hadn't needed attention > to it before when C did it automagically. > cheers -ben > Of course, Ben, i understand that you may miss some of the feature(s), you get used to when doing things in C. But then consider what is involved to implement such feature because it means determining argument types at run time (at compile time it is impossible as well as 'compile once when it is invoked for the first time' that NB does ) That means that no matter how well you try, the implementation will suck.. because it will be very slow comparing to one that uses fixed-type fixed-argument number. My philosophy , in general, for programming is avoid bloat and inefficiency at all costs. When some feature requires bloat and going to be very inefficient, i simply saying 'No'. Especially at infrastructural level, which NB belongs to. Because one thing that you (of me) as implementer knows what is fast & cool and what is slow & inefficient, but then users come and start using things in a way you would never think your stuff will be ever used.. and start spreading inefficiency in their project(s). And more that that, once they get used to it, then you would be never able to remove it because it is there and everyone using it and some even loving it :) -- Best regards, Igor Stasenko.

July 27, 2015