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

Git refreshing

by Peter UhnÃ¡k

Hi, I'm facing a problem with branches and refreshing the code. Currently I handle (except for commits) everything from commandline, but the problem is that when I switch branches I don't know how to easily refresh the code. What I am doing now is running loading Baseline again, but that feels odd. Git revolves around branches, and being able to quickly create them, switch them, and merge them is important. So is there currently any solution that could resolve this? Maybe I could run some code that would simply load what is on the disk? If I switch branches for java code, the editor automatically loads new content without me needing to do any extra work; it would be nice to have something similar. Peter

March 1, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sabine Manaa

Hi Sven, thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. Concerning my workaround: If remove the line where the exception is thrown in >>fillBytes:startingAt:count: "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." Then it works. So, it seems that ignoring the exception would fix the problem for me: [| theZnClient | theZnClient := ZnClient new systemPolicy ; https; host: 'user.gini.net'; path: 'oauth/token?grant_type=client_credentials'; username: 'spesenfuchs' password: 'asdf'; accept: ZnMimeType applicationJson; get. ] on: Error do: [ :ex | ex resume ]. But this needs that the exception is resumable. So could you perhaps make the exception resumable? ZdcSecureSocketStream>>sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ]) >>error: uses Error and this is not resumable. Could you make the Exception resumable? Then perhaps Johan could use resume, to? What is your opinion about this? Do I miss something here? Regards Sabine 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] < ml-node+s1294792n4808670h65(a)n4.nabble.com>: > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4808670&i=0>> wrote: > > > > Excuse the silly question but what exactly is a plugin? Is it the code > which is called by the primitive? The problem is not within the pharo code > itself, right? It is the result of the primitive, which is wrong, right? > > Yes, we're talking about primitives. Plugins group primitives, some > plugins are builtin, others are more like dynamic libraries, and live > separate from the VM. > > The problem is that the C and OS implementations are different for each > platform. Which can result in very subtle semantic differences. In this > case it has something to do with detecting/handling a closed socket stream. > > > Can I do something more to solve the problem or should I try to write a > workaround for me (exception handler and grab the result of the request)? > > From a user standpoint, no. We have a reproducible case now. Thanks for > that. > > I am indeed afraid that you might need to think about a workaround, I > can't promise anything about fixing this. Of course, anyone is free to > help. > > Sven > > > Regards > > Sabine > > > > > > Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > > Arg, and on Linux it works too. > > > > Below the image layer, the normal Pharo code that we see, both the > Socket plugin and the SSL plugin are three totally different > implementations. This is really frustrating. The Mac code originates from > *before* Mac OS X came on the scene ! Today, Mac OS X could probably use > 99% of the Linux version. > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4808670&i=1>> wrote: > > > > > > Hi, > > > > > > I tried on Windows, there it works. > > > > > > Sabine > > > > > > > > > > > > -- > > > View this message in context: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 1, 2015

Re: [Pharo-users] SQLite3 - External module not found

by phil＠highoctane.be

I've got a project using SQLite3 that I wanted to work on again. FWIW, I got smashed by a bug in the current SQLite3 code. The SQLiteconnection>>finalize method is wrong, as the self close in there has the following code: finalize self close. close self unregister. self isOpen ifTrue: [SqliteLibrary default close: reference]. reference := nil. #unregister is unregister self class registry remove: self ifAbsent: [] But, thing is that if close is called in finalize, is looking for reference, but reference is invalid because the object is not valid anymore. So, it appears to work and at one point (after, say, a number of execution of statements), the gc will kick in and try to finalize and the vm will bomb because te reference passed to SqliteLibrary default close: will just be something weird. A fix is to: * first get rid of the finalize method (One can just rename it to finalize_dont in order to not lose it just in case * modify open open reference := SqliteLibrary default open: fileName. self flag: #TODO. "This is fucked up" "self register." * modify close close self flag: #TODO. "This is fucked up. Fix it." "self unregister." self isOpen ifTrue: [SqliteLibrary default close: reference]. reference := nil. To get a connection: sqliteDb ^ db ifNil: [ db := SQLiteConnection fileNamed: (FileSystem disk workingDirectory / 'datasources' / 'data.db') fullName. ] Do a query: | result | result := self sqliteDb execute: 'SELECT * FROM question LIMIT ?' args: {aRowCount}. ^result. or self sqliteDb execute: 'SELECT * FROM writtenquestion LIMIT ?' args: {aRowCount} do: aBlock. HTH Phil On Sun, Mar 1, 2015 at 2:10 PM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > here's Torsten Bergmann's email astares(a)gmx.de > and blogspot http://astares.blogspot.com.ar/ > > get it in contact with him, and you may write some helpful documentation :) > > Thanks. > > On Sun, Mar 1, 2015 at 5:30 AM, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> Also, it would be great to give more details about the installation on >> Smalltalkhub (http://smalltalkhub.com/#!/~PharoExtras/NBSQLite3) and >> there is absolutely no details in >> http://smalltalkhub.com/#!/~TorstenBergmann/SQLite. >> >> I think it would be great to give precisions about the version of the >> lib etc >> >> Maybe also give the exact commands to have it fully working on each >> platforms? >> >> Who do I have to contact if I want to help by writing a little bit more >> about installation details? >> >> I mean no offense, I just want to help next people that will have >> troubles with that :p >> >> Julien >> > > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America.

March 1, 2015

Re: [Pharo-users] SQLite3 - External module not found

by phil＠highoctane.be

You are welcome. I tried to load the tests for the SQLite3 configuration but there was an issue there. I fixed the configuration in the Metarepo for 3.0 Now (ConfigurationOfSQLite3 project version: #stable) load: 'Tests' works. I am using sudo yum install sqlite.i686 to load sqlite3 in my CentOS linux. Then I've copied the lib from /usr/lib into the pharo-vm/ folder and made a: ln -s libsqlite3.so.0.8.6 libsqlite3 The 'sqlite3' name is in SqliteLibrary>>moduleName Phil On Sun, Mar 1, 2015 at 9:04 AM, Julien Delplanque <julien(a)tamere.eu> wrote: > Ok, first of all I made a mistake in my description, the file in the > pharo vm's "bin" directory was well named libsqlite3.so. > > The problem seems to be that /usr/lib/libsqlite3.so.0.8.6 is a 64bits > version. > > Using readelf, I get (in french sorry): > > $ readelf -h /usr/lib/libsqlite3.so.0.8.6 > En-tÃªte ELF: > Magique: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Classe: ELF64 > DonnÃ©es: complÃ©ment Ã 2, systÃ¨me Ã octets de > poids faible d'abord (little endian) > Version: 1 (current) > OS/ABI: UNIX - System V > Version ABI: 0 > Type: DYN (fichier objet partagÃ©) > Machine: Advanced Micro Devices X86-64 > Version: 0x1 > Adresse du point d'entrÃ©e: 0xba00 > DÃ©but des en-tÃªtes de programme : 64 (octets dans le fichier) > DÃ©but des en-tÃªtes de section : 816368 (octets dans le fichier) > Fanions: 0x0 > Taille de cet en-tÃªte: 64 (octets) > Taille de l'en-tÃªte du programme: 56 (octets) > Nombre d'en-tÃªte du programme: 7 > Taille des en-tÃªtes de section: 64 (octets) > Nombre d'en-tÃªtes de section: 27 > Table d'indexes des chaÃ®nes d'en-tÃªte de section: 26 > > I couldn't find a 32 bit version of the package in Arch repositories > (maybe I don't search well?). > > So I searched on google and found a 32bit version. I just c/c it in the > pharo vm's bin directory and.... it worked! > > The the problem was the version of the lib (64 vs 32bit). > > Once again, thanks a lot :) > > Julien > > > >

March 1, 2015

Re: [Pharo-users] Git (gitfiletree) on Pharo vs Windows

by Thierry Goubier

Le 01/03/2015 13:39, Ben Coman a Ã©crit : > > > On Sun, Mar 1, 2015 at 7:17 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > > On Sun, Mar 1, 2015 at 5:19 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 01/03/2015 09:54, Jan B. a Ã©crit : > > A Pharo gui for git would be an excellent thing. As you (and > Alan Kay) know, > simple things should be simple, complex things should be > possible... With > git itself and its command line, there are lots of complex > things possible, > but my opinion is that simple thing are far from simple with > git. > > > I do agree with you on that simple things are far from simple > with git ;) and complex things are complex, and things that we > shouldn't be doing are possible :) > > Nice example of git gui I personally like is github for mac > (and github for > windows). > https://mac.github.com https://windows.github.com > > > :( No mac, no windows here... > > Of course, it is just for github, but it contains all things > one usually > needs for commiting, branching etc. in the gui and if > something is not so > simple, it has command line, too. > > > I think this 'GUI for usual things', 'command line for the rest' > is probably the pragmatic solution. > > So, just for inspiration of overall design... how hard > implementation for > git in general might be, that is another thing. > > > There is a possibility there, which is offered by libcgit > integration in Pharo. If one wanted to do a full GUI > integration, then it could be easier to do it that way (i.e. > low-level access to git concepts, better mastery of those > concepts since their understanding is needed when integrating > into Pharo).. instead of a high-level flying overhead like > GitFileTree does. > > Max, Esteban, what do you think? > > The other one is to focus on VCS overall, and to consider > Monticello GUI refactoring to support concepts such as branches > and external merging, so that it could be portable to other VCS > (svn, mercurial, bazaar) and support whatever flow is needed out > there (see my point during PharoDays 2015). > > It could even allow us to let branches appear in .mcz > repositories :) > > Thierry > > > I believe there would be some advantage to having a general git GUI > app on Pharo for: > * providing a test bed for Pharo libcgit integration > * for others to get some familiarity with Pharo libcgit usage, > before adapting any core Pharo to make use of it > * it would be an app that "I" would have the power to add features to > > > I meant to add, this might make an attractive GSoC project. I'll add it then. Thierry

March 1, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sven Van Caekenberghe

> On 01 Mar 2015, at 13:14, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? >From a user standpoint, no. We have a reproducible case now. Thanks for that. I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. Sven > Regards > Sabine > > > Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > Arg, and on Linux it works too. > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > On 01 Mar 2015, at 10:29, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > > > Hi, > > > > I tried on Windows, there it works. > > > > Sabine > > > > > > > > -- > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

March 1, 2015

Re: [Pharo-users] SQLite3 - External module not found

by Bernardo Ezequiel Contreras

here's Torsten Bergmann's email astares(a)gmx.de and blogspot http://astares.blogspot.com.ar/ get it in contact with him, and you may write some helpful documentation :) Thanks. On Sun, Mar 1, 2015 at 5:30 AM, Julien Delplanque <julien(a)tamere.eu> wrote: > Also, it would be great to give more details about the installation on > Smalltalkhub (http://smalltalkhub.com/#!/~PharoExtras/NBSQLite3) and > there is absolutely no details in > http://smalltalkhub.com/#!/~TorstenBergmann/SQLite. > > I think it would be great to give precisions about the version of the > lib etc > > Maybe also give the exact commands to have it fully working on each > platforms? > > Who do I have to contact if I want to help by writing a little bit more > about installation details? > > I mean no offense, I just want to help next people that will have > troubles with that :p > > Julien > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

March 1, 2015

Re: [Pharo-users] [ANN] Language Detection API Client

by Alexandre Bergel

Wow !! Excellent!! > Le 28 fÃ©vr. 2015 Ã 01:48, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> a Ã©crit : > > Hello, > > Language Detection API is a service to query the language of a given input text. You will need to register an API key in the web site http://detectlanguage.com to use the service. > > This client enables to use the service from Pharo Smalltalk. The output is an object containing the language code, a confidence score and a 'is reliable' boolean value. > > Installation and usage details in the following post: > > http://80738163270632.blogspot.com.ar/2015/02/languagedetection-api-client-… > > Cheers, > > HernÃ¡n > >

March 1, 2015

Re: [Pharo-users] Git (gitfiletree) on Pharo vs Windows

by Ben Coman

On Sun, Mar 1, 2015 at 7:17 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sun, Mar 1, 2015 at 5:19 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> Le 01/03/2015 09:54, Jan B. a Ã©crit : >> >>> A Pharo gui for git would be an excellent thing. As you (and Alan Kay) >>> know, >>> simple things should be simple, complex things should be possible... With >>> git itself and its command line, there are lots of complex things >>> possible, >>> but my opinion is that simple thing are far from simple with git. >>> >> >> I do agree with you on that simple things are far from simple with git ;) >> and complex things are complex, and things that we shouldn't be doing are >> possible :) >> >> Nice example of git gui I personally like is github for mac (and github >>> for >>> windows). >>> https://mac.github.com https://windows.github.com >>> >> >> :( No mac, no windows here... >> >> Of course, it is just for github, but it contains all things one usually >>> needs for commiting, branching etc. in the gui and if something is not so >>> simple, it has command line, too. >>> >> >> I think this 'GUI for usual things', 'command line for the rest' is >> probably the pragmatic solution. >> >> So, just for inspiration of overall design... how hard implementation for >>> git in general might be, that is another thing. >>> >> >> There is a possibility there, which is offered by libcgit integration in >> Pharo. If one wanted to do a full GUI integration, then it could be easier >> to do it that way (i.e. low-level access to git concepts, better mastery of >> those concepts since their understanding is needed when integrating into >> Pharo).. instead of a high-level flying overhead like GitFileTree does. >> >> Max, Esteban, what do you think? >> >> The other one is to focus on VCS overall, and to consider Monticello GUI >> refactoring to support concepts such as branches and external merging, so >> that it could be portable to other VCS (svn, mercurial, bazaar) and support >> whatever flow is needed out there (see my point during PharoDays 2015). >> >> It could even allow us to let branches appear in .mcz repositories :) >> >> Thierry >> > > I believe there would be some advantage to having a general git GUI app on > Pharo for: > * providing a test bed for Pharo libcgit integration > * for others to get some familiarity with Pharo libcgit usage, before > adapting any core Pharo to make use of it > * it would be an app that "I" would have the power to add features to > > I meant to add, this might make an attractive GSoC project.

March 1, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sabine Manaa

Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? Regards Sabine Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > Arg, and on Linux it works too. > > Below the image layer, the normal Pharo code that we see, both the Socket > plugin and the SSL plugin are three totally different implementations. This > is really frustrating. The Mac code originates from *before* Mac OS X came > on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > On 01 Mar 2015, at 10:29, Sabine Manaa <manaa.sabine(a)gmail.com > <javascript:;>> wrote: > > > > Hi, > > > > I tried on Windows, there it works. > > > > Sabine > > > > > > > > -- > > View this message in context: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

March 1, 2015