- Pharo-dev - lists.pharo.org

XMLParser does not close input stream

by paolo.bernardi.67＠gmail.com

hi, after parsing the input stream is left open, so Dia can't save the next version of my toy-designs. added streamReader stream close. at the end of XMLParserTokenizer>>nextEndDocument this made Dia (and me) happy. cheers

Feb. 18, 2014

Re: [Pharo-dev] FFI blowfish for encrypting / decrypting [WAS] Re: How to encrypt a password?

by Ron Teitelbaum

Hi Mariano, Before I give you an answer, you should never ever ever not even for any reason, ever, did I mention ever, store a user's password. You can hash a password, which means you store the hash value of the password. You can make it more secure by salting the hash or embedding your own key to the hash, or doing a number of other things. But you should always store an encrypted hash and never a recoverable password. The way this works is that your user knows the password and can generate a hash at any time that you can compare. You store the hash of the password to compare. The reason for this should be obvious. You don't want anyone to have access to that password. Not even programmers. Your program doesn't need it either since the user can generate that hash for you at any time. It really is all you ever need to store. If you are looking for a simple cypher for something other than a password how about ARC4 from www.squeaksrouce.com/Cryptography |key cText pText| key := SecureRandom picker nextBits: 254. cText := (ARC4 new key: key) encrypt: 'This is a very secure but meaningless string' asByteArray. pText := (ARC4 new key: key) decrypt: cText. ^pText asString 'This is a very secure but meaningless string' It's pretty simple. To get the plainText back all you need is the key. All the best, Ron Teitelbaum From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Mariano Martinez Peck Sent: Monday, February 17, 2014 4:17 PM To: Pharo Development List; glass(a)lists.gemtalksystems.com; The general-purpose Squeak developers list Subject: [Pharo-dev] FFI blowfish for encrypting / decrypting [WAS] Re: How to encrypt a password? On Thu, Nov 21, 2013 at 3:53 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: Mariano Martinez Peck wrote > Hi Paul, and just to be sure I understand...none of them could work as a > two-way encryption, right? > The only one is your Pharo's version of Blowfish but that only works with > 8 > chars long. Is it like this? Or is there any other two-way encryption? > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com Yes that's right. The PasswordHashingFFI stuff is all one way encryption. Blowfish is two way, and the current implementation only works for 8 byte chunks. I stopped working on it when the Smalltalk bcrypt implementation I wanted proved to be 5000x times slower than the FFI version. Someone needs to add the CBC part to Blowfish to encrypt longer strings. I do not know of another in image two way encryption scheme, but there may be something in the Cryptography repo. I'm not sure. Hi Paul, Sorry for the cross posting. I was using the Smalltalk version of the Blowfish you did to encrypt and decrypt things. But now I realize it is very very slow for the usage I need. You seem to have faced the same problem. I am encrypting pieces of 8 characters long. But I wonder if the decryption is available as well in FFI version? I see #ffiCrypt:with: but nothing to decrypt... Thanks in advance -- Mariano http://marianopeck.wordpress.com

Feb. 17, 2014

FFI blowfish for encrypting / decrypting [WAS] Re: How to encrypt a password?

by Mariano Martinez Peck

On Thu, Nov 21, 2013 at 3:53 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Mariano Martinez Peck wrote > > Hi Paul, and just to be sure I understand...none of them could work as a > > two-way encryption, right? > > The only one is your Pharo's version of Blowfish but that only works with > > 8 > > chars long. Is it like this? Or is there any other two-way encryption? > > > > Thanks! > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > Yes that's right. The PasswordHashingFFI stuff is all one way encryption. > Blowfish is two way, and the current implementation only works for 8 byte > chunks. I stopped working on it when the Smalltalk bcrypt implementation I > wanted proved to be 5000x times slower than the FFI version. Someone needs > to add the CBC part to Blowfish to encrypt longer strings. I do not know > of > another in image two way encryption scheme, but there may be something in > the Cryptography repo. I'm not sure. > > > Hi Paul, Sorry for the cross posting. I was using the Smalltalk version of the Blowfish you did to encrypt and decrypt things. But now I realize it is very very slow for the usage I need. You seem to have faced the same problem. I am encrypting pieces of 8 characters long. But I wonder if the *decryption* is available as well in FFI version? I see #ffiCrypt:with: but nothing to decrypt... Thanks in advance -- Mariano http://marianopeck.wordpress.com

Feb. 17, 2014

Re: [Pharo-dev] fuel on pharo 3

by Max Leske

oops, wanted to send it directlyâ¦ On 17.02.2014, at 21:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > because it is already there, probably :) Yeah, thatâs what I think but I want to be sure :) > > On 17 Feb 2014, at 20:55, Max Leske <maxleske(a)gmail.com> wrote: > >> Sebastian, >> >> I dug up this post by accident, but: did you run into errors? Or why did you think that Fuel didnât get loaded? >> >> Cheers, >> Max >> >> >> On 04.01.2014, at 14:30, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> cool >>> >>> thanks >>> >>> >>> On Jan 4, 2014, at 11:23 AM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: >>> >>>> How you guys are loading fuel on Pharo 3? >>>> >>>> This isn't getting that done: >>>> >>>> Gofer new >>>> url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; >>>> package: 'ConfigurationOfFuel'; >>>> load. >>>> >>>> ((Smalltalk at: #ConfigurationOfFuel) project version: #stable) load. >>>> >>>> >>> >>> >> >> > >

Feb. 17, 2014

Re: [Pharo-dev] Update Fuel documentation

by Max Leske

And in regard to this first e-mail: On 01.11.2013, at 21:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > This page http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… has obsolete information, at least for Squeak installation. Iâve run into a problem with the installer which is related to the MIME type used by Smalltalkhub (see squeak dev list). So at the moment Installer isnât an option anyway (Iâm overriding a method in Squeak at the moment to make the Squeak CI builds workâ¦ ). I would defenitely want to update that information. > > This is because ConfigurationOfFuel-MaxLeske.178 still points to old repository http://ss3.gemstone.com/ss/Fuel.html which has been drained... > ConfigurationOfFuel-MartinDias.209 should be a better starting point. > > In latest Squeak trunk there is another problem: lack of squeak4.5.x support both in ConfigurationOfFuel and MetacelloSqueakPlatform>>defaultPlatformAttributes. > But it's another problem, not related to documentation We have a hack for that in the new configuration. Cheers, Max

Feb. 17, 2014

Re: [Pharo-dev] fuel on pharo 3

by Esteban Lorenzano

because it is already there, probably :) On 17 Feb 2014, at 20:55, Max Leske <maxleske(a)gmail.com> wrote: > Sebastian, > > I dug up this post by accident, but: did you run into errors? Or why did you think that Fuel didnât get loaded? > > Cheers, > Max > > > On 04.01.2014, at 14:30, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> cool >> >> thanks >> >> >> On Jan 4, 2014, at 11:23 AM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: >> >>> How you guys are loading fuel on Pharo 3? >>> >>> This isn't getting that done: >>> >>> Gofer new >>> url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; >>> package: 'ConfigurationOfFuel'; >>> load. >>> >>> ((Smalltalk at: #ConfigurationOfFuel) project version: #stable) load. >>> >>> >> >> > >

Feb. 17, 2014

Re: [Pharo-dev] fuel on pharo 3

by Max Leske

Sebastian, I dug up this post by accident, but: did you run into errors? Or why did you think that Fuel didnât get loaded? Cheers, Max On 04.01.2014, at 14:30, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > cool > > thanks > > > On Jan 4, 2014, at 11:23 AM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > >> How you guys are loading fuel on Pharo 3? >> >> This isn't getting that done: >> >> Gofer new >> url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; >> package: 'ConfigurationOfFuel'; >> load. >> >> ((Smalltalk at: #ConfigurationOfFuel) project version: #stable) load. >> >> > >

Feb. 17, 2014

Re: [Pharo-dev] Fuel: fix for Squeak trunk

by Max Leske

On 02.11.2013, at 14:43, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I've opened https://code.google.com/p/fuel/issues/detail?id=204 with an attachment integrated. > > Also note https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg… backported / integrated. Thanks for the pointers. > > > 2013/11/2 Max Leske <maxleske(a)gmail.com> > So far we donât have a public inbox and Iâm not too familiar with STHub and read/write permissions. Concerning your suggestion from the other thread a public inbox would certainly make sense though. > Iâll let you know what we can come up with (STHub seems to be down right now so I canât even give you access right now. But you can send me your fix through mail). > > Max > > On 02.11.2013, at 09:46, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Thanks, and is there a public .mcz inbox, or does it require special rights? >> >> >> 2013/11/2 Max Leske <maxleske(a)gmail.com> >> The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ >> >> On 01.11.2013, at 22:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> > I have an easy fix for Fuel on Squeak trunk. >> > It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... >> > Is there a dedicated bug tracker? >> > What is the preferred procedure? >> > >> > Nicolas >> >> >> > >

Feb. 17, 2014

Re: [Pharo-dev] GSoC: call for ideas

by Christophe Demarey

Hello, Here is another proposal: Description: Automatic dependency analysis of a project Summary: When developing, you often need to use external libraries (yes, you don't want to reinvent the wheel). These dependencies should be expressed explicitly but we always forgot to do it. The idea of this project is to create a tool that will analyze your project packages (source code) and detect references that are not resolved. It will helps developers to express dependencies but also enables automatic dependency analysis to detect wrong project configurations. The second part of this project will consist into giving feedback on undesired package cycles (with live feedback if possible). Dialect: Pharo Skill level: intermediate Mentors: Christophe Demarey <christophe.demarey(a)inria.fr> and HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> Regards, Christophe. Le 11 fÃ©vr. 2014 Ã 10:42, Damien Cassou a Ã©crit : > Hi fellow Pharo hackers, > > ESUG, the European Smalltalk User Group, is applying for this > year's Google Summer of Code. As you probably know, the Summer > of Code provides the opportunity to fund students to work during > the summer on Pharo. Please reply to this > email (be sure to use "Reply to all") if you have ideas you > would like to propose. > > Please include a summary of the project and links to web pages > that can help prospective students to write their application. > Please also include the following information: > > - if applicable, other dialects that you would be willing to > mentor this project for > > - the skill level > > - name of the mentor(s), email addresses, and possibly any IRC > network/channel/nickname where they can be found. > > Thanks for contributing to ESUG's Summer of Code application! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Feb. 17, 2014

Re: [Pharo-dev] Package for manage USB - RS232

by Dario Trussardi

Some consideration: in any case the SerialPort after the first open don't close right the connection. ( and raise the problem as in my last email. ) From other program i can't manage the RS232 device until i close the Pharo image, even if all SerialPort instances are close. Thanks, Dario > Ciao, > >> Try adding (Smalltalk garbageCollect) after the #close. > > I add it, but after the SerialPort allInstances return an array with aSerialPort. > > Strange it's close. > > > I found what "generate" the problem it's in the openPort: method. > > ---------------------------------------------------------------- > openPort: portId > "Open the given serial port, using the settings specified by my > instance variables." > > | result | > > self close. > > "8-10 - wks - this has to tell us if it fails: step 1, save the primitive result" > result := portId isString > ifTrue: [self > primOpenPortByName: portId > baudRate: baudRate > stopBitsType: stopBitsType > parityType: parityType > dataBits: dataBits > inFlowControlType: inputFlowControlType > outFlowControlType: outputFlowControlType > xOnByte: xOnByte > xOffByte: xOffByte] > ifFalse: [self > primOpenPort: portId > baudRate: baudRate > stopBitsType: stopBitsType > parityType: parityType > dataBits: dataBits > inFlowControlType: inputFlowControlType > outFlowControlType: outputFlowControlType > xOnByte: xOnByte > xOffByte: xOffByte]. > > "wks - raise an error if there was a failure." > result isNil ifTrue:[ self error:'Cannot open ', portId printString. ]. > > port := portId > > _------------------------------------------------ > > The result isNotNil the thirst time i call the openPort: it's set at aSerialPort > > isNil the last time i call the openPort > > But if i remove the test : result isNil ifTrue:[ self error:'Cannot open ', portId printString. ]. > > all works fine the first and the following call. > > There is something wrong in the primitive call answer. > > Anyone is expert in this ? > > > Thanks, > > Dario > >> >> Now a question of my own for the list. Why does it seem common to do three #garbageCollects in a row. >> >> cheers -ben >> >> >> Sven Van Caekenberghe wrote: >>> >>> Dario, >>> >>> On 17 Feb 2014, at 12:55, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: >>> >>> >>>> Thanks Sven, >>>> >>>> >>>>> You should #close the port when you are done, else it remains in use, I would guess. >>>>> >>>> Of course, i used : >>>> >>>> >>>> | srl | >>>> srl := SerialPort new. >>>> srl openPort: 'COM1'. >>>> >>>> srl nextPutAll: #[ 27 66 2 2 ] . >>>> >>>> srl close. >>>> >>>> But after the first time, when submit the same code the system answer: >>>> >>>> Error: Cannot open 'COM1' >>>> >>>> I don't unterstand because. >>>> >>> >>> Me neither. I have no experience working with serial ports (but I know some people on the list do), let alone on Windows, but from looking at the code #close should be enough. >>> >>> >>>> I note what the sometimes SerialPort allInstances answer instance after the close method. >>>> >>>> Perhaps remain occupied some resources? >>>> >>> >>> They are still there because they are not yet garbage collected. If they are properly closed (check the printString in the inspector), the external resource should have been released. >>> >>> Sorry, but I can't help you any further. >>> >>> Sven >>> >>> >>>> Ciao, >>>> >>>> Dario >>>> >>>> >>>>> Also, why do you #close before you start, seems strange to me ? >>>>> >>>>> On 17 Feb 2014, at 12:05, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: >>>>> >>>>> >>>>>> Ciao, >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm also interested by an answer to that question. So far, what I have as status is: you need a plugin to handle communications with the serial port (either for direct RS232 or USB-to-Serial) and compiling the serial port plugin with the Pharo VM makes it unstable. >>>>>>> >>>>>> I dont know " compiling " plugin area. ( i work with Windows 7 ) >>>>>> >>>>>> >>>>>>> The solution we used was: to compile the serial plugin for the squeak VM and work in Squeak (4.3) instead of Pharo. >>>>>>> >>>>>> Can you explain more detail about it? >>>>>> >>>>>> >>>>>> My test is : >>>>>> >>>>>> >>>>>> I download the Pharo 2.0 #20628 and i use the SerialPort class. >>>>>> >>>>>> The first time i do the code: >>>>>> >>>>>> | srl | >>>>>> >>>>>> srl := SerialPort new. >>>>>> srl close. >>>>>> >>>>>> srl openPort: 'COM1'. >>>>>> >>>>>> srl nextPutAll: #[ 27 66 2 2 ] . >>>>>> >>>>>> The RS232 device work fine. >>>>>> >>>>>> After the first time, when submit the same code the system answer: >>>>>> >>>>>> Error: Cannot open 'COM1' >>>>>> >>>>>> A this time i need to restart the Pharo environment. >>>>>> >>>>>> >>>>>> Any considerations, suggestions ? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Dario >>>>>> >>>>>> >>>>>> >>>>>>> Thierry >>>>>>> >>>>>>> Le 16/02/2014 16:28, Dario Trussardi a Ã©crit : >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> i work with: Pharo1.Latest update: #14445 ( or with: Pharo2.0 Latest update: #20628 ). >>>>>>>> >>>>>>>> >>>>>>>> I'm interested to manage communications with USB or RS232 device. >>>>>>>> >>>>>>>> >>>>>>>> I can find package which support this protocol? >>>>>>>> >>>>>>>> Thank for any considerations ? >>>>>>>> >>>>>>>> Dario >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Thierry Goubier >>>>>>> CEA list >>>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>>> 91191 Gif sur Yvette Cedex >>>>>>> France >>>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >> >

Feb. 17, 2014