September 2017 - Pharo-dev - lists.pharo.org

Recommendation for password encryption?
by Mariano Martinez Peck Sept. 30, 2022

Sept. 30, 2022

Hi guys. Some time ago I asked about the best way to encrypt a password. Some of the recommendations I got was: 1) Generally for passwords you do not write a decrypt method for security purposes (eg you do not want people to be able to reverse engineer the encrypted password easily) 2) put a little salt 3) There is http://www.squeaksource.com/Cryptography/PasswordHashingFFI 4) I should not decrypt password but instead I should compare both encrypted versions to see if they are equal. My scenario is the following. I need to store database passwords in text files. So I don't want to let them as plain text. And while I understand 4), I think it's a different scenario than mine. I know that some database driver may allow you to directly send the encrypted password. But still...I have another similar scenario in which I have to store a password and then send it (unencrypted)...so I kind of really need a bi-directional encryption. Now..I would try to avoid having an external library + FFI. Any ideas what is the best thing I can do? And how could I solve 1) if I want bidirectional like in my case? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

9 26

Re: [Pharo-project] Parsing and navigating Html
by Paul DeBruicker July 16, 2020

July 16, 2020

On 12/05/2010 06:02 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: > From: St?phane Ducasse<stephane.ducasse(a)inria.fr> > Subject: [Pharo-project] Parsing and navigating Html > To:"Pharo-project(a)lists.gforge.inria.fr Development" > <Pharo-project(a)lists.gforge.inria.fr> > Message-ID:<1C53DFD8-3021-4233-BC83-CE8C1EA8D103(a)inria.fr> > Content-Type: text/plain; charset=us-ascii > > Hi > > I would like extract partial information from HTML pages. > So I started to play and fix HTMLParser. > > Now does anybody know alternatives? > > Second, does anybody develop a lib to query HTML structure as with the XMLSupport package? > > Stef The Soup package on SqueakSource.com works OK.

3 4

Athens based game worked on windows and pharo 60 :)
by stepharong May 2, 2018

May 2, 2018

Hi esteban Today during the labs at the university, we verified with the latest VM on windows that the athens based game that the students were improving is working with Pharo 60 (while some weeks ago when they tried it did not). Stef --

3 2

new pharo cheatsheet
by stepharo March 8, 2018

March 8, 2018

new cheatsheet for Pharo syntax. Any feedback is welcome Stef

18 33

[ANN] Fog - Ethereum driver
by Santiago Bragagnolo Jan. 30, 2018

Jan. 30, 2018

Hi all. Im happy to announce a pre release of the Fog ethereum driver that we develop in the space of an Inria project. It still not complete but is already usable for some experiments and simple projects. You can downloadit from https://github.com/sbragagnolo/Fog/ (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1) Dependencies <https://github.com/sbragagnolo/Fog#rhash>RHash sudo apt-get install rhash <https://github.com/sbragagnolo/Fog#solidity>Solidity npm install solc <https://github.com/sbragagnolo/Fog#download-code>Download code <https://github.com/sbragagnolo/Fog#iceberg--baseline>Iceberg / Baseline Metacello new baseline: 'Fog'; repository: 'github://sbragagnolo/Fog:v0.1.1.1/src'; load. <https://github.com/sbragagnolo/Fog#by-hand>By hand You may want to use this version for having access to some scripts and contracts samples. git checkout git@github.com:sbragagnolo/Fog.git git checkout v0.1.1.1 Metacello new baseline: 'Fog'; repository: 'filetree:///path/to/git-repository/Fog/src';; load. It's based on the standar API for javascript ( https://github.com/ethereum/wiki/wiki/JavaScript-API) . It provides interaction with remote contracts, it do as well provides a way for navigating the architecture objects: blocks, transactions, accounts and contracts. I hope you find it useful. Feel free to fill the github issue tracker with anything you find :). I will come to you with some new exciting news about ethereum soon :) Santiago.

5 9

Re: [Pharo-dev] PharoSpur32Vm
by HernÃ¡n Morales Durand Dec. 30, 2017

Dec. 30, 2017

2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > Hm, I tried to create the build environment used for the > windows vm build from opensmalltalk. > > I setup a cygwin environment with the same install commands as from > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml > > My problems, first it is missing make and wget, I can add make and wget to the install command line for cygwin, but I am > curious why it is working on the build server ? > > Anyway, after I got this working, the build stops and building the pkg-config package. > The log says it can not find a gcc, I know that the build process with cygwin uses > i686-w64-mingw32-gcc > or > x86_64-w64-mingw32-gcc > > But I don't understand where is the missing step to tell the configure scripts to use the > > i686-w64-mingw32-gcc command instead of "gcc", > > again, this seems to work on the appveyor build but not locally on my machine. > > Any idea what I had missed? > I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the line: MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" to MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin" And finally source /etc/profile Cheers, HernÃ¡n > > nicolai > > > > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: >>> >>> I made my own build here. >>> Not up to date with latest stuff but should work for the build process. >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> It uses my forked repo and provided you set your own bintray env vars for API keys will publish there. >>> >>> Check all of the output of env vars and where/which in the appveyor console to see what gets used when when it comes to compilers and so on as there were various compiler versions involved at one point. >>> >>> Third party cache part is also worth checking. >>> >>> Still not able to build on my local box at the moment due to some tools discrepancies happening. >>> >>> My build artifacts are embarking too much at this point but allow you ro get the release, debug, and assert vms for windows. This helps when debugging as backtraces and so on are much more meaningful and one can use gdb more effectively to understand what is going on. >>> >>> Just keep the dlls and exes and you'll be fine. >> >> >> Ah good, thank you. >> >> >>> >>> >>> HTH >>> >>> Phil >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>>> >>>> >>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>>> >>>>>>>> Hi Nicolai, >>>>>>>> >>>>>>>> If you look at appveyor.yml configuration on https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see that the pharo brand is not yet in the matrix. >>>>>>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, some library used by some plugin required by pharo refuse to compile with cygwin. They appear to work with mingw32. >>>>>>>> Cygwin provides headers for legacy directx, some distribution of mingw32 did in the past, but it does not seem the case anymore. >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They are not redistributable and can't be found anymore on the net (too old). We cannot seriously base the builds on something so fragile (both technically and legally) in the long term. >>>>>>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have anything available as a 64bits Microsoft SDK... So pharo has to fix that too. >>>>>>>> >>>>>>>> In the interim, you should look at https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. >>>>>>> >>>>>>> >>>>>>> Ok, thank you. >>>>>>> >>>>>> >>>>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in Nantes, and I almost succeeded in compiling all the dependencies with cygwin. >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely forget a few other niceties that some not so well informed programmers committed with the faith that it would make their life "easier". It certainly does not make mine simpler... >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems that the workaround of Igor does not work anymore. >>>>>> ssize_t, WTF??? >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll publish the branch to see how far appveyor goes. >>>>>> >>>>>> >>>>> >>>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor which is not necessary anymore... >>>>> But got another problem soon after while building the tests... >>>>> There are trailing lines generated at end of tests/cairo-test-constructors.c that make the compilation fail: >>>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-unused-but-set-variable -D_REENTRANT -m32 -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> oning (); >>>>> ^ >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ in declaration of âoningâ [-Wimplicit-int] >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> _register_ft_show_glyphs_table (); >>>>> ^ >>>>> >>>>> And the file looks like it has obviously been overwritten, but not truncated !!! >>>>> >>>>> ... >>>>> extern void _register_multi_page (void); >>>>> extern void _register_fallback_resolution (void); >>>>> >>>>> void >>>>> _cairo_test_runner_register_tests (void) >>>>> { >>>>> _register_a1_bug (); >>>>> _register_a1_clip_paint (); >>>>> ... >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> oning (); >>>>> _register_ft_show_glyphs_table (); >>>>> _register_ft_text_vertical_layout_type1 (); >>>>> _register_ft_text_vertical_layout_type3 (); >>>>> _register_ft_text_antialias_none (); >>>>> _register_ps_eps (); >>>>> _register_ps_features (); >>>>> _register_ps_surface_source (); >>>>> _register_svg_surface (); >>>>> _register_svg_clip (); >>>>> _register_svg_surface_source (); >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> >>>>> This file is generated by a shell script test/make-cairo-test-constructors.sh >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 does not solve the issue. >>>>> So it will wait until tomorrow... >>>> >>>> >>>> >>>> I got the build for windows with mingw nearly working. (it can not build some plugins, like SqueakSSL for windows, because the used wincrypt.h is different in the mingw distrubtion). >>>> >>>> I still have the problem, that there seems to be a preprocessing step , that should put the vm-version (and source timestamp) in the sqSCCSVersion.h >>>> I got this working by running .travis_build.sh (with the options for arch/flavor/platform) But how is this done normally when you build a vm locally? >>>> And how is this done for the pharo-vm we currently use? >>>> >>>> >>>>> >>>>> >>>>> Nicolas >>>>> >>>>>>>> >>>>>>>> I hope that Esteban will find time to resolve all these problems and have pharo brand back on opensmalltalk-vm. I guess that any form of help is welcome. >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>> I still have problems building a vm on windows. >>>>>>>>> can you give me some hints how to start ? >>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>> run >>>>>>>>> mvm >>>>>>>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not found, I had to adjust the include path for finding directx header, missing variable replacement for git-versions). >>>>>>>>> So I may miss some important steps. >>>>>>>>> Is there a repository where I can clone the mingw environment used to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Nicolai >>>>>>>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe they're built from https://github.com/OpenSmalltalk/vm using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>> instead, they are built here: https://github.com/pharo-project/pharo-vm >>>>>>>>>>>> >>>>>>>>>>>> (README still not updated) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows anymore (something wrong with generating the generator.image, I'll now reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> see attached the stderr log : >>>>>>>>>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st' >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on master ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> nicolai >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >

4 5

Re: [Pharo-dev] Two tables that share the same data source!?
by Aliaksei Syrel Dec. 9, 2017

Dec. 9, 2017

Hello Elhamer, Do you have an idea when it might be useful to have two lists representing the same datasource? We have this feature in bloc (see video in attachment) but I didn't encounter a real-life use-case yet... Cheers, Alex â Bloc-TwoListsOneDataSource.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVWpYdzF5dmlIT2Ftbm9yUVBpazNMVE…> â On 8 August 2017 at 02:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hello Elhamer, > > Do you have an idea when it might be useful to have two lists representing > the same datasource? > We have this feature in bloc (see video in attachment) but I didn't > encounter a real-life use-case yet... > > Cheers, > Alex > > On 8 August 2017 at 01:36, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > >> Hello everybody, >> >> How common is it for multiple tables (FastTables) to have the same >> datasource ? >> >> The FTDataSource has a instance variable to refer a table: >> >> ```` >> Object subclass: #FTDataSource >> instanceVariableNames: 'table' >> classVariableNames: '' >> package: 'Morphic-Widgets-FastTable-DataSource' >> ``` >> >> >> which makes it impossible for several tables to have the same data source. >> the code of the data source is also coupled to the ft code which also >> makes >> it harder to extend. >> >> I've tried to go down the rabbit hole and decouple the data source from >> the >> table but things went messy. So i would like to know how common it is for >> several tables to share the same ds, and does that worth going the extra >> mile ? >> >> Thanks, >> Elhamer. >> >> >> >> -- >> View this message in context: http://forum.world.st/Two-tabl >> es-that-share-the-same-data-source-tp4959153.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

3 2

FFIIntegerTypes inheritance hierarchy
by Ben Coman Nov. 28, 2017

Nov. 28, 2017

I'm looking through the keyhole at something new to me, so maybe this is off base, but looking at the inheritance hierarchy... FFIIntegerType FFIUint16 FFIUint16 FFIUInt32 FFIInt32 FFIUint64 FFIInt64 FFIUint8 FFIInt8 I'm curious... why the all the Ints inherit from the UInts? Each of those classes has the same two methods #basicHandle:at: and #basicHandle:at:put. So the Int subclasses fully override the superclass methods. So there in no inherited behaviour on the instance side. On the class side, I see #externalTypeSize is inherited by the Ints, but evaluating... FFIIntegerType allSubclasses collect: [ :class | class externalType byteSize -> class externalTypeSize ] produces... 4->4 2->2 4->4 8->8 1->1 2->2 4->4 8->8 1->1 So naively the extra inheritance level seems unnecessary and perhaps having... FFIIntegerType class >> externalTypeSize ^ self externalType byteSize would allow the hierarchy to be flattened. Maybe not a great benefit, except to avoid the next person wondering the same thing :P Also, it is surprising that that FFUInt64 uses #signedLongLongAt: rather than #unsignedLongLongAt: . This seems on-purpose rather than accidental since its inherited by FFIInt64, so it seems there is something interesting to learn here that would benefit a method comment. cheers -ben

2 2

bloc readiness for a simple mindmap
by Peter Uhnak Nov. 26, 2017

Nov. 26, 2017

Hi, I wanted to ask about Bloc: 1) how stable is the API? e.g. if some overhaul changes to unify/whatever are planned 2) I saw in the techtalk that you can align elements (to center, bottom, ...), however is that possible with lines? Lines have to rotate, morph shape, etc. 3) Are non-straight lines possible? (e.g. bezier, arc) The idea for me is to make a simple mindmap - elements with some text, icons, math symbols inside - connectors (non-straight lines) between elements To me (apart from the lines) it seems like it should be already doable. Also either my (Morphic) Pharo is really slow, or Bloc (in the video) is superfast (everything is happening instantly). Thanks, Peter

7 14

Layout in bloc
by Alexandre Bergel Nov. 25, 2017

Nov. 25, 2017

Hi! I am working on a popup support in Bloc and I am facing a problem. Consider the following code: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= space := BlSpace new. space root layout: BlLinearLayout horizontal. 10 timesRepeat: [ | e | e := (BlRectangle new extent: 20 @ 20) asElement. e background: Color random. space root addChild: e ]. space root children withIndexDo: [ :e :index | e translateBy: (index * 30) @ 10 ]. space root children do: [ :e | e addEventHandler: (BlEventHandler on: BlMouseEnterEvent do: [ :evt | | txt | txt := BlText new position: evt position; fill: Color red; text: 'Hello World'. e parent addChild: txt ]). ]. space show -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you uncomment the second line (âspace root layout:â¦â), then the string hello world is added text to the element in which the mouse enter. With the layout, the string is added at the end of the line. I like very much the idea of having the layout applied when elements are added (even I suspect we may have scalability issues very soon), but in that situation, this is not wished. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4