- Pharo-users - lists.pharo.org

Pharo for Raspberry Pi

by horrido

I'm following Torsten's article, "Pharo Pi," to setup my new Raspberry Pi 3. The only differences are: 1) I'm using 63.zip for the VM instead of 61.zip; 2) I'm using Pharo V50 instead of V40. However, I'm getting the following error when I try to run Pharo: *This interpreter (vers. 6505) cannot read image file (vers. 6521).* Any idea what's going on? -- View this message in context: http://forum.world.st/Pharo-for-Raspberry-Pi-tp4945740.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 6, 2017

Re: [Pharo-users] [ANN] git migration tool

by Stephane Ducasse

What I can tell you is that I do not know for sure how to do it :) On Sat, May 6, 2017 at 2:29 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > the code generated from the migration tool can be used by both Iceberg and > GitFileTree (because they both use FileTree format to store the code). > > So you can just migrate your code, install Iceberg and you're good to go. > I can write a blog post about this I guess... > > (maybe I could add the migration to icerberg, but I need to check if > libgit2 can do the importing part) > > > Peter > > > > On Sat, May 06, 2017 at 08:56:51AM +0200, Stephane Ducasse wrote: > > Peter > > > > what is the path to migrate MCZ project from SmalltalkHub to github and > > that we can use them with > > Iceberg. > > > > Stef > > > > On Sat, May 6, 2017 at 8:44 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > > > > > this is super cool!!!! > > > Tx a lot peter for that. > > > > > > On Thu, May 4, 2017 at 2:32 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > >> With Iceberg knocking on the door, migration from SmalltalkHub to > > >> Git(Hub/Lab/...) has become relevant once more. > > >> > > >> And that's why I wrote git-migration tool https://github.com/peteru > > >> hnak/git-migration to help you move on to greener pastures. > > >> > > >> Among other things described in the too-long-didn't read README: > > >> > > >> the tool will generate git-fast-import (a special format for fast git > > >> imports) file that can be easily and quickly applied on your git > repository. > > >> All commits are preserved in their proper order, and merges (commits > with > > >> multiple parents) are also converted to git merges. > > >> > > >> So far I've tested it on my custom intentionally broken repository, > and > > >> PolyMath. > > >> > > >> PolyMath has 784 commits in 74 packages; it took Pharo about 3 > minutes to > > >> process all SmalltalkHub commits and generate 87MB file; git then > imported > > >> the file in less than a second. > > >> > > >> > > >> (Git history of PolyMath in GitKraken) > > >> > > >> the tool also provides you with a bunch of visualizations that can > help > > >> you analyze your SmalltakHub history and investigate problems. > > >> > > >> > > >> (trees of all packages in the PolyMath repository) > > >> > > >> More things could be desired (e.g. even better performance), so feel > free > > >> to open issues, ideally with pull requests. ;) > > >> > > >> Peter > > >> > > > > > > > > > > >

May 6, 2017

Re: [Pharo-users] [ANN] git migration tool

by Peter Uhnak

Hi, the code generated from the migration tool can be used by both Iceberg and GitFileTree (because they both use FileTree format to store the code). So you can just migrate your code, install Iceberg and you're good to go. I can write a blog post about this I guess... (maybe I could add the migration to icerberg, but I need to check if libgit2 can do the importing part) Peter On Sat, May 06, 2017 at 08:56:51AM +0200, Stephane Ducasse wrote: > Peter > > what is the path to migrate MCZ project from SmalltalkHub to github and > that we can use them with > Iceberg. > > Stef > > On Sat, May 6, 2017 at 8:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > this is super cool!!!! > > Tx a lot peter for that. > > > > On Thu, May 4, 2017 at 2:32 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > >> With Iceberg knocking on the door, migration from SmalltalkHub to > >> Git(Hub/Lab/...) has become relevant once more. > >> > >> And that's why I wrote git-migration tool https://github.com/peteru > >> hnak/git-migration to help you move on to greener pastures. > >> > >> Among other things described in the too-long-didn't read README: > >> > >> the tool will generate git-fast-import (a special format for fast git > >> imports) file that can be easily and quickly applied on your git repository. > >> All commits are preserved in their proper order, and merges (commits with > >> multiple parents) are also converted to git merges. > >> > >> So far I've tested it on my custom intentionally broken repository, and > >> PolyMath. > >> > >> PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to > >> process all SmalltalkHub commits and generate 87MB file; git then imported > >> the file in less than a second. > >> > >> > >> (Git history of PolyMath in GitKraken) > >> > >> the tool also provides you with a bunch of visualizations that can help > >> you analyze your SmalltakHub history and investigate problems. > >> > >> > >> (trees of all packages in the PolyMath repository) > >> > >> More things could be desired (e.g. even better performance), so feel free > >> to open issues, ideally with pull requests. ;) > >> > >> Peter > >> > > > >

May 6, 2017

Re: [Pharo-users] XMLHTMLParser Entity Handling oddity

by Stephane Ducasse

Hi guys It would be supercool to have a chapter on the XML package. Does any of you have the knowledge to do it? I do not have it. Stef On Sat, May 6, 2017 at 9:51 AM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > Perfect! Thank you very very much! > > Am 05/05/17 um 19:28 schrieb monty: > > This should be fixed now. Thanks for the bug report. >> >> Sent: Wednesday, May 03, 2017 at 4:44 PM >>> From: "Udo Schneider" <udo.schneider(a)homeaddress.de> >>> To: pharo-users(a)lists.pharo.org >>> Subject: [Pharo-users] XMLHTMLParser Entity Handling oddity >>> >>> All, >>> >>> I'm hitting an interesting issue with XMLHTMLParser and I'm not even >>> sure if this is a bug or intended behaviour. Given an HTML Entity in a >>> String it's resolved or quoted depending on the tag (header or section >>> tag): >>> >>> doc := XMLHTMLParser parse: >>> '<html><head><title>Ã</title></head><body>Ã</body></html>'. >>> (doc findElementNamed: 'title') contentString. "'Ã'" >>> (doc findElementNamed: 'body') contentString. "'Ã'" >>> >>> In my understanding and according to >>> https://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Entities in the >>> title tag are allowed and should IMHO be resolved. >>> >>> So both should return 'Ã' in this case. >>> >>> Any pointers? >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> >> >> > > >

May 6, 2017

Re: [Pharo-users] XMLHTMLParser Entity Handling oddity

by Udo Schneider

Perfect! Thank you very very much! Am 05/05/17 um 19:28 schrieb monty: > This should be fixed now. Thanks for the bug report. > >> Sent: Wednesday, May 03, 2017 at 4:44 PM >> From: "Udo Schneider" <udo.schneider(a)homeaddress.de> >> To: pharo-users(a)lists.pharo.org >> Subject: [Pharo-users] XMLHTMLParser Entity Handling oddity >> >> All, >> >> I'm hitting an interesting issue with XMLHTMLParser and I'm not even >> sure if this is a bug or intended behaviour. Given an HTML Entity in a >> String it's resolved or quoted depending on the tag (header or section tag): >> >> doc := XMLHTMLParser parse: >> '<html><head><title>Ã</title></head><body>Ã</body></html>'. >> (doc findElementNamed: 'title') contentString. "'Ã'" >> (doc findElementNamed: 'body') contentString. "'Ã'" >> >> In my understanding and according to >> https://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Entities in the >> title tag are allowed and should IMHO be resolved. >> >> So both should return 'Ã' in this case. >> >> Any pointers? >> >> CU, >> >> Udo >> >> >> > >

May 6, 2017

Re: [Pharo-users] [ANN] git migration tool

by Stephane Ducasse

Peter what is the path to migrate MCZ project from SmalltalkHub to github and that we can use them with Iceberg. Stef On Sat, May 6, 2017 at 8:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > this is super cool!!!! > Tx a lot peter for that. > > On Thu, May 4, 2017 at 2:32 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> With Iceberg knocking on the door, migration from SmalltalkHub to >> Git(Hub/Lab/...) has become relevant once more. >> >> And that's why I wrote git-migration tool https://github.com/peteru >> hnak/git-migration to help you move on to greener pastures. >> >> Among other things described in the too-long-didn't read README: >> >> the tool will generate git-fast-import (a special format for fast git >> imports) file that can be easily and quickly applied on your git repository. >> All commits are preserved in their proper order, and merges (commits with >> multiple parents) are also converted to git merges. >> >> So far I've tested it on my custom intentionally broken repository, and >> PolyMath. >> >> PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to >> process all SmalltalkHub commits and generate 87MB file; git then imported >> the file in less than a second. >> >> >> (Git history of PolyMath in GitKraken) >> >> the tool also provides you with a bunch of visualizations that can help >> you analyze your SmalltakHub history and investigate problems. >> >> >> (trees of all packages in the PolyMath repository) >> >> More things could be desired (e.g. even better performance), so feel free >> to open issues, ideally with pull requests. ;) >> >> Peter >> > >

May 6, 2017

Re: [Pharo-users] [ANN] git migration tool

by Stephane Ducasse

this is super cool!!!! Tx a lot peter for that. On Thu, May 4, 2017 at 2:32 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > With Iceberg knocking on the door, migration from SmalltalkHub to > Git(Hub/Lab/...) has become relevant once more. > > And that's why I wrote git-migration tool https://github.com/ > peteruhnak/git-migration to help you move on to greener pastures. > > Among other things described in the too-long-didn't read README: > > the tool will generate git-fast-import (a special format for fast git > imports) file that can be easily and quickly applied on your git repository. > All commits are preserved in their proper order, and merges (commits with > multiple parents) are also converted to git merges. > > So far I've tested it on my custom intentionally broken repository, and > PolyMath. > > PolyMath has 784 commits in 74 packages; it took Pharo about 3 minutes to > process all SmalltalkHub commits and generate 87MB file; git then imported > the file in less than a second. > > > (Git history of PolyMath in GitKraken) > > the tool also provides you with a bunch of visualizations that can help > you analyze your SmalltakHub history and investigate problems. > > > (trees of all packages in the PolyMath repository) > > More things could be desired (e.g. even better performance), so feel free > to open issues, ideally with pull requests. ;) > > Peter >

May 6, 2017

Re: [Pharo-users] XMLHTMLParser Entity Handling oddity

by Stephane Ducasse

Tx monty for the fix! On Fri, May 5, 2017 at 7:28 PM, monty <monty2(a)programmer.net> wrote: > This should be fixed now. Thanks for the bug report. > > > Sent: Wednesday, May 03, 2017 at 4:44 PM > > From: "Udo Schneider" <udo.schneider(a)homeaddress.de> > > To: pharo-users(a)lists.pharo.org > > Subject: [Pharo-users] XMLHTMLParser Entity Handling oddity > > > > All, > > > > I'm hitting an interesting issue with XMLHTMLParser and I'm not even > > sure if this is a bug or intended behaviour. Given an HTML Entity in a > > String it's resolved or quoted depending on the tag (header or section > tag): > > > > doc := XMLHTMLParser parse: > > '<html><head><title>Ã</title></head><body>Ã</body></html>'. > > (doc findElementNamed: 'title') contentString. "'Ã'" > > (doc findElementNamed: 'body') contentString. "'Ã'" > > > > In my understanding and according to > > https://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Entities in the > > title tag are allowed and should IMHO be resolved. > > > > So both should return 'Ã' in this case. > > > > Any pointers? > > > > CU, > > > > Udo > > > > > > > >

May 6, 2017

Re: [Pharo-users] XMLHTMLParser Entity Handling oddity

by monty

This should be fixed now. Thanks for the bug report. > Sent: Wednesday, May 03, 2017 at 4:44 PM > From: "Udo Schneider" <udo.schneider(a)homeaddress.de> > To: pharo-users(a)lists.pharo.org > Subject: [Pharo-users] XMLHTMLParser Entity Handling oddity > > All, > > I'm hitting an interesting issue with XMLHTMLParser and I'm not even > sure if this is a bug or intended behaviour. Given an HTML Entity in a > String it's resolved or quoted depending on the tag (header or section tag): > > doc := XMLHTMLParser parse: > '<html><head><title>Ã</title></head><body>Ã</body></html>'. > (doc findElementNamed: 'title') contentString. "'Ã'" > (doc findElementNamed: 'body') contentString. "'Ã'" > > In my understanding and according to > https://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Entities in the > title tag are allowed and should IMHO be resolved. > > So both should return 'Ã' in this case. > > Any pointers? > > CU, > > Udo > > >

May 5, 2017

Re: [Pharo-users] Smalltalk syntactic coloration in Spec's TextModel

by Julien Delplanque

Thanks, it works perfectly. Julien On 04/05/17 13:11, Nicolai Hess wrote: > 2017-05-04 12:53 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: > >> Thanks, it works. >> >> Another question: Is it possible to manage the fact that the >> code displayed is a method? (ie not having the selector and >> instance variables causing the syntactic coloration to be >> red) >> > Yes, setting the behavior (class of the method): > > TextModel new > isForSmalltalkCode: true; > text: (Collection>>#anyOne) sourceCode; > aboutToStyle: true; > behavior: (Collection>>#anyOne) methodClass; > openWithSpec > > >> Thanks in advance, >> >> Julien >> >> >> >> On 03/05/17 17:09, Nicolai Hess wrote: >> >>> 2017-05-03 16:57 GMT+02:00 Julien Delplanque <julien(a)tamere.eu>: >>> >>> Hello, >>>> I looked in the mailing list archive but did not found an answer. >>>> >>>> Is there any way to have Smalltalk syntactic coloration in a TextModel >>>> without having to put efforts in it? >>>> >>>> I mean, if I do: >>>> >>>> TextModel new >>>> isForSmalltalkCode: true; >>>> text: (Collection>>#any) sourceCode; >>>> openWithSpec >>>> >>>> The text displayed is black. >>>> >>>> Thanks in advance, >>>> >>>> Julien >>>> >>>> >>>> >>>> Hi, >>> you need to add >>> aboutToStyle:true >>> >>> >>> >>> TextModel new >>> isForSmalltalkCode: true; >>> text: (Collection>>#anyOne) sourceCode; >>> aboutToStyle: true; >>> openWithSpec >>> >>> >>

May 4, 2017