[Pharo-dev] Auto-documenting your Pharo-projects
Hi everyone. Following yesterday’s discussion about WebDoc, I’m pleased to share with you my new blog post with a tutorial how to generate documentation on CI: http://sleepycoders.blogspot.com/2014/05/auto-documenting-your-pharo-projects.html Cheers. Uko
Re: [Pharo-dev] 32 bits and 64 bits VM
On 15 May 2014, at 18:46, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Great. As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)? I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits… that’s another very different history: - you need a 64bits image (so trace, export, etc.) - you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all) Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm. Now. In the agenda for this year is to work on a 64bits spur version. If everything is fine and the stars align properly, it will be ready around christmas. Esteban Hilaire Le 15/05/2014 18:24, Esteban Lorenzano a écrit : so yes… I integrated the fix, created a pull request, waited until validation… and then I forget to merge :S it should be in process to build now. -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] Auto-documenting your Pharo-projects
how exactly it works ? it documents class and method comments ? Or you can add also additional text to it ? On Fri, May 16, 2014 at 10:49 AM, Yuriy Tymchuk yuriy.tymc...@me.comwrote: Hi everyone. Following yesterday’s discussion about WebDoc, I’m pleased to share with you my new blog post with a tutorial how to generate documentation on CI: http://sleepycoders.blogspot.com/2014/05/auto-documenting-your-pharo-projects.html Cheers. Uko
Re: [Pharo-dev] Auto-documenting your Pharo-projects
It is like JavaDoc, based on class and method comments. On 16 May 2014, at 10:53, kilon alios kilon.al...@gmail.com wrote: how exactly it works ? it documents class and method comments ? Or you can add also additional text to it ? On Fri, May 16, 2014 at 10:49 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi everyone. Following yesterday’s discussion about WebDoc, I’m pleased to share with you my new blog post with a tutorial how to generate documentation on CI: http://sleepycoders.blogspot.com/2014/05/auto-documenting-your-pharo-projects.html Cheers. Uko
[Pharo-dev] Spotlight
Hello, There are a couple of things that do get on my nerves with Spotlight, namely that it lists all kinds of symbols that have nothing to do in the search list, e.g. Globals (Display), old classes that aren't there anymore etc. that it is on the top right,making me look away from the code etc. I want this in the middle of the screen, like in Eclipse for example. Also, if I type in Display, I'd like to inspect it right away (I know I can do that with :expr but still as I forget it all the time, I've put a reminder in the box). Next, I do not want to search, I want to find, so, ghosttext changed accordingly. So, I had a look and changed it to be the way I wanted. It is much more usable that way as far as I am concerned. If you want to try this, just file in the attached change set or get https://gist.github.com/philippeback/f43447ec2bddcd3f9b84 What would also nice it to be able to have the autocompletion list wider. Any idea on how to do just that? (yes, I have long class names...) Feedback welcome. Phil Spotlight.st Description: application/vnd.sailingtracker.track
[Pharo-dev] Method recategorization - call for help
Hi, if you would like to contribute to better Pharo modularization and you do not know how, I have a tip for you. Following methods are extension methods of various packages that extend classes in Morphic-Core package. We need to move them directly to Morphic-Core package so we have to place them in different categories. Example: Morph organization classify: #handleMouseWheel: under: 'events-processing'. Morph organization classify: #handlesMouseWheel: under: 'events-processing' Methods: Morph organization classify: #layoutChanged under: 'recategorized'. PasteUpMorph organization classify: #resizeBackgroundMorph under: 'recategorized'. PasteUpMorph organization classify: #backgroundMorph under: 'recategorized'. Color organization classify: #fillRectangle:on: under: 'recategorized'. Morph organization classify: #rejectsEvent: under: 'recategorized'. Morph organization classify: #privateMoveBy: under: 'recategorized'. Morph organization classify: #rejectsEvent: under: 'recategorized'. Morph organization classify: #changed under: 'recategorized'. Morph organization classify: #handlesDropShadowInHand under: 'recategorized'. Morph organization classify: #layoutChanged under: 'recategorized'. Morph organization classify: #morphicLayerNumberWithin: under: 'recategorized'. Morph organization classify: #morphicLayerNumberWithin: under: 'recategorized'. Morph organization classify: #handlesMouseOver: under: 'recategorized'. Morph organization classify: #privateMoveBy: under: 'recategorized'. Morph organization classify: #rejectsEvent: under: 'recategorized'. Morph organization classify: #changed under: 'recategorized'. Morph organization classify: #handlesDropShadowInHand under: 'recategorized'. Morph organization classify: #ayoutChanged under: 'recategorized'. Morph organization classify: #morphicLayerNumberWithin: under: 'recategorized'. Morph organization classify: #handlesMouseOver: under: 'recategorized'. HandMorph organization classify: #fullDrawOn: under: 'recategorized'. HandMorph organization classify: #fullDrawOn: under: 'recategorized'. PasteUpMorph organization classify: #resizeBackgroundMorph under: 'recategorized'. PasteUpMorph organization classify: #handlerForMouseDown: under: 'recategorized'. PasteUpMorph organization classify: #backgroundMorph under: 'recategorized'. PasteUpMorph organization classify: #resizeBackgroundMorph under: 'recategorized'. PasteUpMorph organization classify: #handlerForMouseDown: under: 'recategorized'. PasteUpMorph organization classify: #backgroundMorph under: 'recategorized'. Color organization classify: #fillRectangle:on: under: 'recategorized'. That is not all. There is a lot of methods that do not need to be in Morphic-Core package. Most of them will be moved to Morphic-Base package but it is not good to place them directly to '*Morphic-Base' category. We should create categories like '*Morphic-Base-something' or place this methods to some more fitting packages. WorldMorph class organization classify: #installNewWorld under: '*Morphic-Base'. BorderStyle class organization classify: #raised under: '*Morphic-Base'. BorderStyle class organization classify: #complexAltRaised under: '*Morphic-Base'. BorderStyle class organization classify: #complexAltFramed under: '*Morphic-Base'. BorderStyle class organization classify: #complexAltInset under: '*Morphic-Base'. BorderStyle class organization classify: #inset under: '*Morphic-Base'. BorderStyle class organization classify: #simple under: '*Morphic-Base'. BorderStyle class organization classify: #complexInset under: '*Morphic-Base'. BorderStyle class organization classify: #width:color: under: '*Morphic-Base'. BorderStyle class organization classify: #complexRaised under: '*Morphic-Base'. BorderStyle class organization classify: #complexFramed under: '*Morphic-Base'. BorderedMorph class organization classify: #exampleGradient under: '*Morphic-Base'. WorldState class organization classify: #startThenBrowseMessageTally under: '*Morphic-Base'. WorldState class organization classify: #startMessageTally under: '*Morphic-Base'. WorldState class organization classify: #windowsOn: under: '*Morphic-Base'. WorldState class organization classify: #systemOn: under: '*Morphic-Base'. GrafPort organization classify: #displayScannerFor:foreground:background:ignoreColorChanges: under: '*Morphic-Base'. Canvas organization classify: #asAlphaBlendingCanvas: under: '*Morphic-Base'. Canvas organization classify: #copyClipRect: under: '*Morphic-Base'. WorldMorph organization classify: #acceptDroppingMorph:event: under: '*Morphic-Base'. WorldMorph organization classify: #install under: '*Morphic-Base'. WorldMorph organization classify: #installForUIProcessReinstall under: '*Morphic-Base'. WorldMorph organization classify: #dispatchKeystroke: under: '*Morphic-Base'. BorderedMorph organization classify: #changeBorderWidth: under: '*Morphic-Base'. BorderedMorph organization classify: #splitters under: '*Morphic-Base'. BorderedMorph
Re: [Pharo-dev] Auto-documenting your Pharo-projects
ah nice this is very cool :) are there any other features or thats about it ? On Fri, May 16, 2014 at 12:00 PM, Sven Van Caekenberghe s...@stfx.euwrote: It is like JavaDoc, based on class and method comments. On 16 May 2014, at 10:53, kilon alios kilon.al...@gmail.com wrote: how exactly it works ? it documents class and method comments ? Or you can add also additional text to it ? On Fri, May 16, 2014 at 10:49 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi everyone. Following yesterday’s discussion about WebDoc, I’m pleased to share with you my new blog post with a tutorial how to generate documentation on CI: http://sleepycoders.blogspot.com/2014/05/auto-documenting-your-pharo-projects.html Cheers. Uko
Re: [Pharo-dev] Spotlight
Cool ! I haven't loaded your change set yet, but your ideas are good - I agree with all of them. Maybe it would be better to make the placement a setting (a bit like for the growl widget). What I find annoying is that the shortest match is not always chosen, for example when you type String, the String class is not in the top matches, and you have to type a space before hitting return. On 16 May 2014, at 11:02, p...@highoctane.be wrote: Hello, There are a couple of things that do get on my nerves with Spotlight, namely that it lists all kinds of symbols that have nothing to do in the search list, e.g. Globals (Display), old classes that aren't there anymore etc. that it is on the top right,making me look away from the code etc. I want this in the middle of the screen, like in Eclipse for example. Also, if I type in Display, I'd like to inspect it right away (I know I can do that with :expr but still as I forget it all the time, I've put a reminder in the box). Next, I do not want to search, I want to find, so, ghosttext changed accordingly. So, I had a look and changed it to be the way I wanted. It is much more usable that way as far as I am concerned. If you want to try this, just file in the attached change set or get https://gist.github.com/philippeback/f43447ec2bddcd3f9b84 What would also nice it to be able to have the autocompletion list wider. Any idea on how to do just that? (yes, I have long class names...) Feedback welcome. Phil Screenshot-13.pngSpotlight.st
Re: [Pharo-dev] 32 bits and 64 bits VM
* 64-bit aware hashing functions as the current ones are 32-bit centric. This issue might not be the most urgent because the 32 bit hash functions should be sufficient to deal with at least moderately sized 64 bit images. But how much stuff would you have to allocate before seeing a problem? Suppose object headers are 16 bytes and your hash functions are producing 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance variables and zero byte data is kind of silly, so we put in at least one instance variable making those objects at least 24 bytes. Then you also need a hashed collection with a single table large enough to hold all those objects (ignoring e.g. hash buckets), the load factor of which will be kept at 80%. So... 24 * 2^28 * 4 // 5 + (2^28 * 8) = about 7gb So, the current hash functions should be fine for images up to 7gb in size, and probably much larger than that because 7gb is the rock bottom low estimate. Probably one might hash strings or other objects with more data than 8 bytes. In that case, the low bound in that case will be higher. Andres.
Re: [Pharo-dev] 32 bits and 64 bits VM
On Fri, May 16, 2014 at 12:38 PM, Andres Valloud avall...@smalltalk.comcastbiz.net wrote: * 64-bit aware hashing functions as the current ones are 32-bit centric. This issue might not be the most urgent because the 32 bit hash functions should be sufficient to deal with at least moderately sized 64 bit images. But how much stuff would you have to allocate before seeing a problem? Suppose object headers are 16 bytes and your hash functions are producing 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance variables and zero byte data is kind of silly, so we put in at least one instance variable making those objects at least 24 bytes. Then you also need a hashed collection with a single table large enough to hold all those objects (ignoring e.g. hash buckets), the load factor of which will be kept at 80%. So... 24 * 2^28 * 4 // 5 + (2^28 * 8) = about 7gb So, the current hash functions should be fine for images up to 7gb in size, and probably much larger than that because 7gb is the rock bottom low estimate. Probably one might hash strings or other objects with more data than 8 bytes. In that case, the low bound in that case will be higher. Thanks for this, always enlightening. Phil Andres.
[Pharo-dev] R: a Pharo talk from a ruby conference
+1 Lorenzo Schiavina -Messaggio originale- Da: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] Per conto di kmo Inviato: giovedì 15 maggio 2014 20:03 A: pharo-dev@lists.pharo.org Oggetto: Re: [Pharo-dev] a Pharo talk from a ruby conference Looking at the new pharo website (it’s great, by the way), I found I was more upset than I thought I would be by the total absence of the s-word. Perhaps lots of people think smalltalk is a dead language but that’s not the only view of smalltalk that people have out there. I came to pharo looking for a new, better way of developing applications. I knew from reading about the history of computing that smalltalk was the purest object oriented language. I knew that it had pioneered many advanced ideas in program development. I knew that it was so far ahead of its time that other languages were still hobbling along behind it trying to catch up. I knew that java and C# were constantly trying to be more smalltalk-like. So I looked for a smalltalk – ideally an open source smalltalk that I could use on Linux. And so I came to pharo. If someone had told me that pharo was not smalltalk, I would not have been interested, I would have though pharo was just a niche product (like Rebol, say) - something that might simply fade away with no history behind it. And I’m sure there are other people like me out there who also have heard of the smalltalk mystique. This heritage is something to be proud of. So why hide what pharo is? It’s not smalltalk’s reputation as /dead/ that I think is likely to put people off. It’s more smalltalks’s reputation as an academic’s language, used to investigate abstruse computer science problems, but unsuitable for mundane day-to-day development. The sort of language that cannot produce a stand-alone executable (a myth - but pharo could do with a deployment wizard of some kind). The sort of language that can produce incredible data visualisations (Roassal) but is unable to put up a decent data entry screen (Spec). (Sorry, that's unfair but I could not resist it! ) Rather than hide the smalltalk origins of pharo, I think they should be shouted from the rooftops. I would add something like this to the web page. */Pharo is an alive-and-kicking, developer-focused, version of smalltalk – the most beautiful idea in the history of computing./* Just my two cents. By the way, I really don't like the idea of using /agile /as a description of pharo. Agile means almost nothing now - it's just a management buzzword for nothing in particular. -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759204.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] 32 bits and 64 bits VM
the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say: ldd squeakvm Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a). Pharo 2 does not work as this vm is too old. Where am I wrong? Hilaire Le 16/05/2014 10:20, Esteban Lorenzano a écrit : I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits… that’s another very different history: -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] 32 bits and 64 bits VM
Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well. http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-standardvm-running-32-bit-image-on-slackware-linux-14-1-with-32-bit-compat-libs/ (not my work at all - just sharing). -cbc On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say: ldd squeakvm Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a). Pharo 2 does not work as this vm is too old. Where am I wrong? Hilaire Le 16/05/2014 10:20, Esteban Lorenzano a écrit : I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits… that’s another very different history: -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] 32 bits and 64 bits VM
On Wed, May 14, 2014 at 9:08 PM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working Following these simple instructions would have fixed the problem in 2 minutes: http://www.pharo-project.org/pharo-download/ubuntu I run the exact same OS and Pharo works perfectly. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] a Pharo talk from a ruby conference
Esteban A. Maringolo wrote All the previous dialects were advertised as a new Smalltalk dialect ... This time we could, at least, try to advertise it differently. +1. I think that delaying the Smalltalk conversation a bit a la Clojure might be the sweet spot. A good time to mention it might be in describing the language, since it's obviously Smalltalk. I'll reiterate that I strongly feel that the language - which has always been the least interesting thing - should be introduced /last/, after the environment - which is the real blue plane idea here - and the libraries, which are of practical importance. - Cheers, Sean -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759290.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] a Pharo talk from a ruby conference
Once, when I told an old friend I was doing Smalltalk, he asked me Are you doing computer archeology? It is difficult to fight this. Hilaire Le 15/05/2014 22:09, Sergi Reyner a écrit : Pharo is a Smalltalk for the 21st century. - Sergi Reyner. Cheers, Sergi -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] 32 bits and 64 bits VM
I know for years[1], only solve partially, on some Linux distribution, not really user friendly, support of this solution may change over making installation of 32bits libs even more complicated for average user. Now my question was related to 64bits, and I am really curious about this 64bits squeakvm compiled for Debian AMD64 Le 16/05/2014 18:17, Damien Cassou a écrit : On Wed, May 14, 2014 at 9:08 PM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits machine. I could not get it working Following these simple instructions would have fixed the problem in 2 minutes: http://www.pharo-project.org/pharo-download/ubuntu I run the exact same OS and Pharo works perfectly. [1] http://www.drgeo.eu/community/faq#TOC-Can-I-run-it-in-my-Linux-64-bits-host- -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] a Pharo talk from a ruby conference
On Fri, May 16, 2014 at 7:23 PM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Once, when I told an old friend I was doing Smalltalk, he asked me Are you doing computer archeology? It is difficult to fight this. Back to the future after 30 years of spinning your wheels --- Wanting to code at the speed of tought? Wishing the machine was your friend and not a roadblock? Want to burn cash as slow as possible while maximizing your output? If so, get a copy of Pharo! It is not your (grand) daddy's Smalltalk! ;-) Phil Hilaire Le 15/05/2014 22:09, Sergi Reyner a écrit : Pharo is a Smalltalk for the 21st century. - Sergi Reyner. Cheers, Sergi -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] 32 bits and 64 bits VM
On Fri, May 16, 2014 at 10:20:47AM +0200, Esteban Lorenzano wrote: On 15 May 2014, at 18:46, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Great. As we are discussing about build, is it possible to compile CogVM on 64 bits architecture as it is already the case for the interpreted SqueakVM (https://packages.debian.org/sid/squeak-vm)? I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. But to have a 64bits vm that runs on 64bits? that?s another very different history: - you need a 64bits image (so trace, export, etc.) - you need to be 64bits word size aware (not so complicated, but a lot of work). - you need 64bits plugins (a lot of them) - you need 64bits JIT (or no JIT at all) Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image. What squeak guys are doing in the link you provide is still building a 32bits vm. It's experimental 64 bit image is not really all that experimental any more, although Ian still labels it as such on squeakvm.org/unix. A compiled VM is available there. Building it from source is just a matter of specifying --image64 in the configure step, then doing a make. Up to date Squeak trunk images in 64-bit format are traced daily at http://build.squeak.org/job/Squeak%2064-bit%20image/ Dave
Re: [Pharo-dev] a Pharo talk from a ruby conference
To me, “Smalltalk” is everything. Take anything away (language, tools, image, or library) and it’s not nearly as interesting. On May 16, 2014, at 12:04 PM, Sean P. DeNigris s...@clipperadams.com wrote: Esteban A. Maringolo wrote All the previous dialects were advertised as a new Smalltalk dialect ... This time we could, at least, try to advertise it differently. +1. I think that delaying the Smalltalk conversation a bit a la Clojure might be the sweet spot. A good time to mention it might be in describing the language, since it's obviously Smalltalk. I'll reiterate that I strongly feel that the language - which has always been the least interesting thing - should be introduced /last/, after the environment - which is the real blue plane idea here - and the libraries, which are of practical importance. - Cheers, Sean -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759290.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Gmail Contact Export and #readStream
Two issues: 1. Exports for Outlook Gmail seems to have inserted 160 asCharacter in a few places in a gmail contact csv export, so for example this partial phone number: '(914) 469-' is written to file as: #[40 57 49 52 41 160 52 54 57 45] And then aFile readStream contents signals ZnInvalidUTF8: Invalid utf8 input detected when it encounters the 160 2. Google csv Exports The file starts with the BOM #[255 254], which generates the same exception = Are these problems with gmail or Pharo? Thanks - Cheers, Sean -- View this message in context: http://forum.world.st/Gmail-Contact-Export-and-readStream-tp4759306.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Gmail Contact Export and #readStream
That is weird indeed, I would say they mixed up Latin1 and UTF8. BTW, if you do #[40 57 49 52 41 160 52 54 57 45] inspect. in Pharo 3, you'll see that it is actually a Latin1 encoded ByteArray, not a UTF8 one. In Latin1 (http://en.wikipedia.org/wiki/Latin1) 160 is NBSP (Non breaking space). In UTF8, this would be encoded differently ZnUTF8Encoder new encodeString: 160 asCharacter asString. #[194 160] But if the file starts with the Unicode BOM, that is really confusing (http://en.wikipedia.org/wiki/Unicode_Byte-Order_Mark#Usage), since in UTF8 it would be different, and from your byte sequence it can't be UTF16 either. On 16 May 2014, at 22:06, Sean P. DeNigris s...@clipperadams.com wrote: Two issues: 1. Exports for Outlook Gmail seems to have inserted 160 asCharacter in a few places in a gmail contact csv export, so for example this partial phone number: '(914) 469-' is written to file as: #[40 57 49 52 41 160 52 54 57 45] And then aFile readStream contents signals ZnInvalidUTF8: Invalid utf8 input detected when it encounters the 160 2. Google csv Exports The file starts with the BOM #[255 254], which generates the same exception = Are these problems with gmail or Pharo? Thanks - Cheers, Sean -- View this message in context: http://forum.world.st/Gmail-Contact-Export-and-readStream-tp4759306.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Gmail Contact Export and #readStream
Sven Van Caekenberghe-2 wrote That is weird indeed, I would say they mixed up Latin1 and UTF8 Yes! Changing to Latin1TextConverter did the trick. I assumed UTF8 because they did not specify and mention UTF8 elsewhere in gmail settings Sven Van Caekenberghe-2 wrote But if the file starts with the Unicode BOM, that is really confusing... since in UTF8 it would be different, and from your byte sequence it can't be UTF16 either. It was UTF16. The byte sequence was from a different output format. Changing to UTF16TextConverter successfully parsed the file. I wonder... can all this be handled automatically? When I open either file in OS X, it seems to just do the right thing. I also wonder why gmail doesn't clearly display the encoding when you're exporting... - Cheers, Sean -- View this message in context: http://forum.world.st/Gmail-Contact-Export-and-readStream-tp4759306p4759320.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] [ANN]: Tiny Gmail Contact Importer
I wrote a tiny utility to work with Gmail contacts. It is very basic and just maps an export file in the Outlook format to GmailContact objects. It doesn't support the Google CSV format - the field order and names are different, and the file is UTF16-encoded. Enjoy! Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; package: 'GmailContact'; load. #GmailContact asClass importAllFromOutlookExport: ‘/path/to/contacts.csv' asFileReference.
