August 2019 - 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

Re: [Pharo-dev] Contribute to pharo8.0 ?
by Ritesh Saini Feb. 24, 2020

Feb. 24, 2020

Having the same issue. Canât fix! Tried everything :( Regards, Ritesh adsense high paying keywords <https://www.digitalkube.com/highest-paying-adsense-niches/>

3 2

Testing "Weekly Digest" for GitHub
by Marcus Denker Sept. 30, 2019

Sept. 30, 2019

Hi, There is a ProBot that creates an issue with a weekly summary. By installing it for testing, we got the first report: Weekly Digest (1 July, 2019 - 8 July, 2019) https://github.com/pharo-project/pharo/issues/381 I will do some fine-tuning (e.g. disable commits and star-gazers) later. We then can let it run for some weeks and see if it is useful or not. Marcus

1 7

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
by monty Sept. 10, 2019

Sept. 10, 2019

I will move it to github, if that makes things easier for everyone else. ___ montyos.wordpress.com > Sent: Wednesday, January 30, 2019 at 3:13 PM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: monty <monty2(a)programmer.net> > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > > > > > On 3 Oct 2018, at 07:43, monty <monty2(a)programmer.net> wrote: > > > > I am the principal maintainer of those projects, but any PharoExtras dev can contribute. And the blog below (which I plan on updating) provides additional information on them. > > Has there been any progress in this area ? > > It would be really great if this important project moved to GitHub. > > Sven > >

8 11

possible Windows Update "1903" Iceberg problem
by Ben Coman Sept. 9, 2019

Sept. 9, 2019

IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? A few other recent reports are noted here... https://github.com/pharo-project/pharo/issues/3418 cheers -ben

7 18

[ANN] Pharo Headless - Beta (Actually what is between Alpha and Beta)
by tesonep＠gmail.com Sept. 5, 2019

Sept. 5, 2019

TL;DR; ====== For the anxious, you can get real headless vm and image from zero-conf. $ wget get.pharo.org/64/80+vmHeadlessLatest | bash Zero conf scripts remain unchanged for users. However, if you are launching the VM by hand from the executable instead of the launcher scripts (pharo and pharo-ui) as in $ ./pharoexecutable Pharo.image the image will launch in headless mode and will not open a window. To launch it in headfull, you can use the --interactive argument after the image, which will make the image open a window using SDL2. $ ./pharoexecutable Pharo.image --interactive Long version ============ Hi, this mail is the happy intermediate result of the work that us, the Pharo Consortium Team, has been doing in the last couple of months. Our main objective is to have a real headless implementation of Pharo where all the responsibility to open or not a World window (or other) is handled by the image. For doing so we have done a series of modifications in the image and the VM side. We consider this is the path that Pharo 8 and following versions should follow, as it will severely improve server-side and command line Pharo and in building custom desktop applications. These modifications are available only in 64-bits machines (Windows, OSX, and Linux). ARM32 and 64bits headless is in the roadmap, but it is delayed because we have prioritized our three major platforms for this first couple of months. All this work is based in Opensmalltalk-VM and Ronnie's initial work on headless. We are really grateful to all the contributors in the history of this nice product. To achieve a real headless VM we have brought modifications in the source tree because most of the platform code to open and manipulate windows is not required anymore. Instead, we use the SDL2 library that implements a nice layer on top of the OS and allows us to manage on the image side through FFI. So this mail is now an open call for (beta?)testing. The sources of the current VM we are building are in the headless branch in https://github.com/pharo-project/opensmalltalk-vm And we have set up a CI that is both building and testing the VM in https://ci.inria.fr/pharo-ci-jenkins2/job/pharo-vm/job/headless/ For the future we have a lot of ideas, that will wait for another long email or a beer-talk @ESUG. We want to hear your ideas!! Image-Side Improvements ======================= - The image handles the creation or not of the main world window. - We incorporated the idea of World renderer, where different backends are used to render the world. - We have 3 backends: VM support (compatibility with non-headless VMs), and OSWindow with two backends: SDL and GTK3+. - The modifications in the image are fully backward compatible with the non-headless VM and are pushed since weeks in the latest 8.0 image. - We move the handling of events to the image side when using SDL and GTK3+, opening the door to a richer set of events and finer-grained control over them. - SDL and GTK versions are implemented using FFI calls. VM-Side Improvements ==================== - VMMaker code migrated to Tonel thanks to Feenk and included in the repository of the VM. - Making VMMaker execute in Pharo 7 and 8. - Removing GPL code from the VM repository (GDB). - Slowly adding new tests for the JIT / Slang and VMGeneration. - Restructuring of the source code. - A new simpler CMake build. - Generate VM code from Slang on each build. - A CI process to validate (including the run of the tests in Pharo and the ones adding to the VM). - Simplification of the codebase. - Maximize the reuse of code between the platforms (preferring the standard versions over the platform-specific). - Cleaning up duplicated code. - All the plugins are now external plugins. - The VM is now a dynamic library. This is a first step towards embedding Pharo into other applications. - The main executable is a thin frontend (you can change it or implement your own). - Removing unused plugins. - Improved crash dump. Especially the crash dump works now in Windows 64bits. - Dummy implementation of Security plugin (it is going away.... eventually). - Cleanup of SSL, UUID, and Socket plugin. - Cleanup of conditional code (Still to improve). - Improving the types used in the functions (we have to be neat to be multiplatform/multi-arch). - Improving the lookup of modules - Improving the logging of the VM - Improving the handling of VM arguments Thanks a lot for reading so long!! We hope you enjoy the VM and please tell us all the problems you find!! Pablo, Guille, and Esteban

7 12

Epicea Feedback
by Sean P. DeNigris Sept. 4, 2019

Sept. 4, 2019

Not complaining at all and appreciate everyone's hard (mostly-unpaid) work, but providing raw feedback in case it's helpful... - Browser awkward: filters disappear whenever left selection changed; no multi-select of sessions, which led to a host of difficulties described below. - What is the heuristic to find API access points? Epicea package has no comment, 'Browser' tag doesn't seem to have an XyzBrowser class, no particular class in the 'Model' tag jumps out at me as an access point; as above Browser about text not set. I finally bring up Morphic halos on the browser and after flopping around, find subclasses of EpLogNode; I browse it and find EpLogNodeGraphModel, which sounds interesting and turns out to be a spec. I figure out how to list the log files, but not how to get the entries - I was expecting a term like that and the relevant method (#log it turns out) has no comment to indicate it's what I'm looking for. Now that I'm starting to understand the project organization, back to the browser to explore EpUnifiedBrowserModel. After a bit of poking around, I suspect (correctly) that #log is what I'm after. Based on code I extract from the browsers and a bit of experimenting in GT, I come up with the following seemingly very complex script: nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore baseLocator. nodes do: [ :node | node populateReferencedNodesWith: nodes ]. nodes flatCollect: [ :n | n log events select: [ :e | e affectedPackageName beginsWith: 'Magritte' ] ] I now run into a series of problems because, although EpCodeChange declares #affectedPackageName as an abstract method, not all events are EpCodeChanges. I exclude EpUndos. Easy enough. Now I come to an EpGenericRefactoring. This one is harder because p.s. <rant>Code names for internal projects seem extremely counterproductive. Hiedra tells me absolutely nothing about functionality. It might as well be called XyzWidgetThing</rant> ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 4

CMake StackInterpreter Headless build
by Ben Coman Sept. 3, 2019

Sept. 3, 2019

How can I build the StackInterpreter with the Pharo Headless build? I tried... -DCOG_JIT:BOOL="False" but get the message... [CMake] CMake Warning: Manually-specified variables were not used by the project: COG_JIT The following with the new binary doesn't distinguish it for me... $ build/vm/pharo --version my.image Pharo 8.1.0 built on Aug 30 2019 18:06:20 Compiler: 7.4.0 Built from: acaeef692 - Commit: acaeef692 - Date: 2019-08-28 22:49:49 +0800 Is there anyway to check that a particular binary is a StackInterpreter? Can this be added to "--version" ? Here is the full log... Found cmake executable at /usr/bin/cmake. 1> /usr/bin/cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCOG_JIT:BOOL="False" -DCMAKE_INSTALL_PREFIX="/mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/out/install/WSL-Debug" "/mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/CMakeLists.txt"; 1> [CMake] -- acaeef692 - Commit: acaeef692 - Date: 2019-08-28 22:49:49 +0800 1> [CMake] -- int 4 1> [CMake] -- long 8 1> [CMake] -- long long 8 1> [CMake] -- void* 8 1> [CMake] -- C Compiler: /usr/bin/cc 1> [CMake] -- C++ Compiler: /usr/bin/c++ 1> [CMake] -- Resource Compiler: 1> [CMake] -- Adding plugin: SecurityPlugin 1> [CMake] -- Adding plugin: FilePlugin 1> [CMake] -- Adding plugin: FileAttributesPlugin 1> [CMake] -- Adding plugin: UUIDPlugin 1> [CMake] -- Adding plugin: SocketPlugin 1> [CMake] -- Adding plugin: SurfacePlugin 1> [CMake] -- Adding plugin: LargeIntegers 1> [CMake] -- Adding plugin: JPEGReaderPlugin 1> [CMake] -- Adding plugin: JPEGReadWriter2Plugin 1> [CMake] -- Adding plugin: MiscPrimitivePlugin 1> [CMake] -- Adding plugin: B2DPlugin 1> [CMake] -- Adding plugin: LocalePlugin 1> [CMake] -- Adding plugin: SqueakSSL 1> [CMake] -- Adding plugin: DSAPrims 1> [CMake] -- Adding plugin: UnixOSProcessPlugin 1> [CMake] Adding third-party libraries for linux: pthreadedPlugin-0.0.1 1> [CMake] Adding third-party libraries for linux: libffi-3.3-rc0 1> [CMake] Adding third-party libraries for linux: libgit2-0.25.1 1> [CMake] Adding third-party libraries for linux: libssh2-1.7.0 1> [CMake] Adding third-party libraries for linux: openssl-1.0.2q 1> [CMake] Adding third-party libraries for linux: SDL2-2.0.7 1> [CMake] -- Configuring done 1> [CMake] -- Generating done 1> [CMake] CMake Warning: 1> [CMake] Manually-specified variables were not used by the project: 1> [CMake] COG_JIT 1> [CMake] -- Build files have been written to: /mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/out/build/WSL-Debug 1> Starting CMake target info extraction ... 1> CMake server connection made. 1> Extracted includes paths. 1> Extracted CMake variables. 1> Extracted source files and headers. 1> Extracted global settings. 1> Extracted code model. 1> Collating data ... 1> Warning: CMake 3.11 or newer is required for install target integration 1> Target info extraction done. 1> CMake generation finished. cheers -ben P.S. btw, the -DCOG_JIT:BOOL="False" comes from first trying-the-simplest-thing of unticking "COG_JIT" in this Visual Studio configuration dialog... [image: image.png]

2 1

[Pharo 8.0] Build #686: 4422-DNU-in-finder-searching-for-print-this-invalid-selector
by ci-pharo-ci-jenkins2＠inria.fr Aug. 31, 2019

Aug. 31, 2019

There is a new Pharo build available! The status of the build #686 was: FAILURE. The Pull Request #4444 was integrated: "4422-DNU-in-finder-searching-for-print-this-invalid-selector" Pull request url: https://github.com/pharo-project/pharo/pull/4444 Issue Url: https://github.com/pharo-project/pharo/issues/4422 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0