May 2017 - Pharo-users - lists.pharo.org

SPEC: accept by Tab ?

by Hartmut Krasemann

Hi, maybe someone can give me a hint. I use SPEC for an elaborate GUI with the need to switch autoaccept of inputFields off. So accept of textInputFields is by Return. Since Tabs are used to navigate anyway, It would be great to "accept" on leaving the inputField. I found the possibility to bind a key/keyCombination to an action (as is done in ButtonModel initialize: self bindKeyCombination: Character space toAction: [ self action ] ) However the following code in a TextinputFieldModel textinputField bindKeyCombination: Character tab toAction: textinputField acceptBlock did not work. What should I do? Thanks for a hint -- signatur Hartmut Krasemann KÃ¶nigsberger Str. 41 c D 22869 Schenefeld Tel. 040.8307097 Mobil 0171.6451283 Krasemann(a)acm.org

May 6, 2017

Re: [Pharo-users] Pharo for Raspberry Pi

by nacho

I guess you will have to check both, the VM and the image are Spur or not. Do not combine them. ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Pharo-for-Raspberry-Pi-tp4945740p4945741.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 6, 2017

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