January 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Annonce Pharo-LibVLC

by Benoit Verhaeghe

Le 12/01/2020 Ã 18:02, HernÃ¡n Morales Durand a Ã©critÂ : > Hi Benoit, > > Thank you for publishing this one! > This is how I installed: > > Iceberg remoteTypeSelector: #scpUrl. > Metacello new > baseline: 'VLC'; > repository: 'github://badetitou/Pharo-LibVLC'; > load. > > However I got this warning on Mac: > > This package depends on the following classes: > Â VLCLibrary > Â VLCLibraryCore > You must resolve these dependencies before you will be able to load > these definitions: > Â VLCLibrary>>#macModuleName > Â VLCLibraryCore>>#macModuleName Oupsi, The bug is fixed now. It was a dependency problem in Pharo7 (in the baseline). I've forgot to check that before the release. > > And consequently all test method fails. Is there something I've missing? > > Cheers, > > HernÃ¡n > > El dom., 12 ene. 2020 a las 12:42, Benoit Verhaeghe > (<badetitou(a)gmail.com <mailto:badetitou@gmail.com>>) escribiÃ³: > > Hello there, > > I just want to let you know that I've developed an FFI binding to VLC. > Since, version 2.1.1 you can use it on Windows, Linux, and OSX. > https://github.com/badetitou/Pharo-LibVLC > > Thanks to the binding you can play easily sounds and videos from > Pharo. > > The next steps are: > > * Documentation and examples (in the Image, GitHub, and a blog > post/tutorial) > * Full Travis testing > * SDL support > * A #Spec2 <https://twitter.com/hashtag/Spec2?src=hashtag_click>UI > * A SeasideUI (https://github.com/pharo-media-center > <https://t.co/Zzlb01Ncw8?amp=1>) > > Feel free to use the binding and tell me if you need help with it. > > BenoÃ®t Verhaeghe > > -- > BenoÃ®t Verhaeghe > badetitou.github.io <http://badetitou.github.io> > > benoit.verhaeghe(a)berger-levrault.com <mailto:benoit.verhaeghe@berger-levrault.com> > R&D Engineer at Berger-Levrault > benoit.verhaeghe(a)inria.fr <mailto:benoit.verhaeghe@inria.fr> > PHD student at Inria-Lille--Nord-Europe > -- BenoÃ®t Verhaeghe badetitou.github.io benoit.verhaeghe(a)berger-levrault.com R&D Engineer at Berger-Levrault benoit.verhaeghe(a)inria.fr PHD student at Inria-Lille--Nord-Europe

Jan. 12, 2020

Re: [Pharo-users] Annonce Pharo-LibVLC

by HernÃ¡n Morales Durand

Hi Benoit, Thank you for publishing this one! This is how I installed: Iceberg remoteTypeSelector: #scpUrl. Metacello new baseline: 'VLC'; repository: 'github://badetitou/Pharo-LibVLC'; load. However I got this warning on Mac: This package depends on the following classes: VLCLibrary VLCLibraryCore You must resolve these dependencies before you will be able to load these definitions: VLCLibrary>>#macModuleName VLCLibraryCore>>#macModuleName And consequently all test method fails. Is there something I've missing? Cheers, HernÃ¡n El dom., 12 ene. 2020 a las 12:42, Benoit Verhaeghe (<badetitou(a)gmail.com>) escribiÃ³: > Hello there, > > I just want to let you know that I've developed an FFI binding to VLC. > Since, version 2.1.1 you can use it on Windows, Linux, and OSX. > https://github.com/badetitou/Pharo-LibVLC > > Thanks to the binding you can play easily sounds and videos from Pharo. > > The next steps are: > > - Documentation and examples (in the Image, GitHub, and a blog > post/tutorial) > - Full Travis testing > - SDL support > - A #Spec2 <https://twitter.com/hashtag/Spec2?src=hashtag_click> UI > - A Seaside UI (https://github.com/pharo-media-center > <https://t.co/Zzlb01Ncw8?amp=1>) > > Feel free to use the binding and tell me if you need help with it. > > BenoÃ®t Verhaeghe > > -- > BenoÃ®t Verhaeghebadetitou.github.io > benoit.verhaeghe(a)berger-levrault.com > R&D Engineer at Berger-Levraultbenoit.verhaeghe(a)inria.fr > PHD student at Inria-Lille--Nord-Europe > >

Jan. 12, 2020

Annonce Pharo-LibVLC

by Benoit Verhaeghe

Hello there, I just want to let you know that I've developed an FFI binding to VLC. Since, version 2.1.1 you can use it on Windows, Linux, and OSX. https://github.com/badetitou/Pharo-LibVLC Thanks to the binding you can play easily sounds and videos from Pharo. The next steps are: * Documentation and examples (in the Image, GitHub, and a blog post/tutorial) * Full Travis testing * SDL support * A #Spec2 <https://twitter.com/hashtag/Spec2?src=hashtag_click>UI * A SeasideUI (https://github.com/pharo-media-center <https://t.co/Zzlb01Ncw8?amp=1>) Feel free to use the binding and tell me if you need help with it. BenoÃ®t Verhaeghe -- BenoÃ®t Verhaeghe badetitou.github.io benoit.verhaeghe(a)berger-levrault.com R&D Engineer at Berger-Levrault benoit.verhaeghe(a)inria.fr PHD student at Inria-Lille--Nord-Europe

Jan. 12, 2020

Re: [Pharo-users] Pharo on OpenSUSE (FFI / libgit2 errors)

by Holger Freyther

It's exclusively due curl-gnutls (libcurl linked against GNUtls instead of OpenSSL for license preference). A version of OpenSSL1.0.0 seems to be in the bundle. This was tested against http://files.pharo.org/get-files/80/pharo64-linux-stable.zip 1.) Download that file 2.) unzip that file somehwere 3.) In the same directory execute the below script. It fetches gnutls-curl from Ubuntu and its dependencies. 4.) Please report if that worked for you or not. #!/usr/bin/env bash # Fetches Ubuntu Xenial dependencies and copy them into the Pharo directory set -ex add_dependencies() { local package="$1" local url="http://mirrors.kernel.org/ubuntu/pool/${package}" wget -O tmp.deb ${url} # TODO(zecke): This avoids using dpkg-deb but assumes a third genration ar x tmp.deb data.tar.xz # TODO(zecke): This assumes multi-arch packaging. It's true now. tar -xv --strip-components=3 -C lib/pharo/5.0-201902062351 -f data.tar.xz ./lib/x86_64-linux-gnu || \ tar -xv --strip-components=4 -C lib/pharo/5.0-201902062351 -f data.tar.xz ./usr/lib/x86_64-linux-gnu # clean-up rm tmp.deb data.tar.xz } add_dependencies main/c/curl/libcurl3-gnutls_7.47.0-1ubuntu2.14_amd64.deb add_dependencies main/r/rtmpdump/librtmp1_2.4+20151223.gitfa8646d-1ubuntu0.1_amd64.deb add_dependencies main/libi/libidn/libidn11_1.32-3ubuntu1.2_amd64.deb add_dependencies main/n/nettle/libnettle6_3.2-1ubuntu0.16.04.1_amd64.deb add_dependencies main/n/nettle/libhogweed4_3.2-1ubuntu0.16.04.1_amd64.deb add_dependencies main/n/nas/libaudio2_1.9.4-4_amd64.deb > On 11. Jan 2020, at 18:24, Holger Freyther <holger(a)freyther.de> wrote: > > Hi, > > I just ran into the very same problem and into further problems when building from source. I will try to see which help I can provide to come to a solution: > > libgit2 requires libssh2 which requires OpenSSL 1.0.x which is not installed/installable. > > Building fails as OpenSUSE puts amd64 libraries into a lib64 folder. Manually copying it around fixes the build. > > I am using OpenSUSE tumbleweed right now (a rolling release Linux distribution). > > holger > > >> On 11. Jan 2020, at 17:47, Jan BlizniÄenko <jan.bliznicenko(a)fit.cvut.cz> wrote: >> >> Hello >> >> I would like to use Pharo on OpenSUSE, which is only Linux distro on our university PCs, however, I am getting FFI to libgit2 related errors just about everywhere. By starting Launcher itself, by starting an image (Pharo 7 and 8) and fetching probably any repository (tried Roassal 2 on Pharo 6, 7, 8). I would really like to be able to use Pharo on university PCs, but I need you help with finding out what might be wrong and what to do about it. The main and only instruction for Linux is currently "Unzip the archive in a place where you have write privileges.", which obviously does not work for OpenSUSE. It works fine for Ubuntu and Debian. >> >> Thank you >> >> Jan >> >> <fetching_roassal.png><starting_launcher.png> >

Jan. 12, 2020

Re: [Pharo-users] Pharo on OpenSUSE (FFI / libgit2 errors)

by Jan BlizniÄenko

Thank you for answer. I remember having to create link to /usr/lib64/libcurl.so.4 2 years ago, with one of previous version of OpenSUSE Leap. Currently there is OpenSUSE Leap 15 and even my package I created 2 years ago for OpenSUSE with copy of libcurl library does not work anymore (same error). ldd libgit2.so gives me: linux-vdso.so.1 (0x00007ffe3e7e1000) libcurl-gnutls.so.4 => not found libz.so.1 => /lib64/libz.so.1 (0x00007f0abed73000) libssl.so.1.0.0 => not found libcrypto.so.1.0.0 => not found libssh2.so.1 => not found librt.so.1 => /lib64/librt.so.1 (0x00007f0abeb6b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0abe94d000) libc.so.6 => /lib64/libc.so.6 (0x00007f0abe593000) /lib64/ld-linux-x86-64.so.2 (0x00007f0abf2cd000) So I tried copying all the libraries with "not found" from /usr/lib64 to pharo-vm/lib/pharo/5.0-201901051900 but it does not seem recognize them anyway - still the same result of ldd libssh2.so Note that I am not very experienced with solving such kinds of problems, so maybe I misunderstand what ldd is telling me. Also that even on Ubuntu I get "not found" for libssh2.so.1, but Pharo works there fine. Probably ldd is not looking for libraries in same directory, but runtime does? Jan Holger Freyther wrote > Hi, > > I just ran into the very same problem and into further problems when > building from source. I will try to see which help I can provide to come > to a solution: > > libgit2 requires libssh2 which requires OpenSSL 1.0.x which is not > installed/installable. > > Building fails as OpenSUSE puts amd64 libraries into a lib64 folder. > Manually copying it around fixes the build. > > I am using OpenSUSE tumbleweed right now (a rolling release Linux > distribution). > > holger > > >> On 11. Jan 2020, at 17:47, Jan BlizniÄenko < > jan.bliznicenko@.cvut > > wrote: >> >> Hello >> >> I would like to use Pharo on OpenSUSE, which is only Linux distro on our >> university PCs, however, I am getting FFI to libgit2 related errors just >> about everywhere. By starting Launcher itself, by starting an image >> (Pharo 7 and 8) and fetching probably any repository (tried Roassal 2 on >> Pharo 6, 7, 8). I would really like to be able to use Pharo on university >> PCs, but I need you help with finding out what might be wrong and what to >> do about it. The main and only instruction for Linux is currently "Unzip >> the archive in a place where you have write privileges.", which obviously >> does not work for OpenSUSE. It works fine for Ubuntu and Debian. >> >> Thank you >> >> Jan >> >> > <fetching_roassal.png> > <starting_launcher.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 11, 2020

Re: [Pharo-users] Pharo on OpenSUSE (FFI / libgit2 errors)

by Holger Freyther

Hi, I just ran into the very same problem and into further problems when building from source. I will try to see which help I can provide to come to a solution: libgit2 requires libssh2 which requires OpenSSL 1.0.x which is not installed/installable. Building fails as OpenSUSE puts amd64 libraries into a lib64 folder. Manually copying it around fixes the build. I am using OpenSUSE tumbleweed right now (a rolling release Linux distribution). holger > On 11. Jan 2020, at 17:47, Jan BlizniÄenko <jan.bliznicenko(a)fit.cvut.cz> wrote: > > Hello > > I would like to use Pharo on OpenSUSE, which is only Linux distro on our university PCs, however, I am getting FFI to libgit2 related errors just about everywhere. By starting Launcher itself, by starting an image (Pharo 7 and 8) and fetching probably any repository (tried Roassal 2 on Pharo 6, 7, 8). I would really like to be able to use Pharo on university PCs, but I need you help with finding out what might be wrong and what to do about it. The main and only instruction for Linux is currently "Unzip the archive in a place where you have write privileges.", which obviously does not work for OpenSUSE. It works fine for Ubuntu and Debian. > > Thank you > > Jan > > <fetching_roassal.png><starting_launcher.png>

Jan. 11, 2020

Pharo on OpenSUSE (FFI / libgit2 errors)

by Jan BlizniÄenko

Hello I would like to use Pharo on OpenSUSE, which is only Linux distro on our university PCs, however, I am getting FFI to libgit2 related errors just about everywhere. By starting Launcher itself, by starting an image (Pharo 7 and 8) and fetching probably any repository (tried Roassal 2 on Pharo 6, 7, 8). I would really like to be able to use Pharo on university PCs, but I need you help with finding out what might be wrong and what to do about it. The main and only instruction for Linux is currently "Unzip the archive in a place where you have write privileges.", which obviously does not work for OpenSUSE. It works fine for Ubuntu and Debian. Thank you Jan

Jan. 11, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Offray Vladimir Luna CÃ¡rdenas

On 10/01/20 1:52 p.Â m., horrido wrote: > Offray Vladimir Luna CÃ¡rdenas-2 wrote >> But I have not >> being able to convince any of my coder friends to switch to Pharo >> instead of C++, Java or Javacript, which by the way, is the language >> they already know and use to put bread on the table on a daily basis. >> >> So I think that we deal with a paradox: while Smalltalk advocacy is >> better suited for a Blue Ocean Strategy[2], exploring and implementing >> new/emerging scenarios and markets, money is already mostly invested in >> Red Oceans of constituted technologies and practices ecosystems. >> Bridging both is pretty difficult. > Yes, that is the principal obstacle and challenge. When I'm pushing > Smalltalk, I mention the language's simplicity and conciseness, I > mention the purity of the object-oriented model, I mention the > built-in IDE, and so on. But the key advantage that I emphasize > is *programmer productivity*. > > I realize it's hard to argue with the availability of jobs for Java, Python, > JavaScript, etc. It's hard to argue with their rich ecosystems. It's > hard to argue with the status quo of established code bases and > IT infrastructures. But we have to make them believe that > Smalltalk can cut their development time in half, if not better. > > What is it worth to a company to cut their development time in half? > It means much lower development cost. It means much shorter > "time to market." > > Is this not worth investing time and energy in Smalltalk? Even if the > job opportunities aren't there. Even if it means overhauling your > IT infrastructure. > > The investment can lead to more users and more jobs. If they don't > believe it, then we have failed. > I have invested time and energy in Smalltalk. Since 2014 I have organized 500+ hours of workshops and hackathons which lead us to our local success story [1]. [1] https://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/success-story.… But, from that experience, I see pretty difficult that coders which are already using other languages and frameworks for their daily jobs, use Pharo/Smalltalk when precisely their jobs is to maintain and extend the stuff that they are already using. I have had better experience with non coders (i.e: librarians, journalists and so on), presenting such "new" ideas and practices. Grafoscopio is suited at non-coders that don't mind to code or are curious about coding, but they need to intertwine code with prose, data and visualization. I think that a place where coders and non-coders can meet is at Blue Ocean places (that's why I'm starting to explore Scuttlebutt protocol). Can we start to find such blue oceans to explore together in a playful and practical sense, where we can showcase the advantages of Pharo/Smalltalk ? That could be a pretty good advocacy. Cheers, Offray

Jan. 11, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

This is exactly why I also push Smalltalk's simplicity. In the 1970s, Per Brinch Hansen posited that a small, simple language would lead to fewer programmer errors. The result of his work was the Edison programming language. It was published in his book, "Programming a Personal Computer," which is one of my favourite programming books. Of course, Per Brinch Hansen wasn't alone in this belief. It was also shared by Niklaus Wirth who created Pascal and Oberon. So it's not just Smalltalk's live programming environment that we should herald. The size and simplicity of the language is a big deal. Richard Sargent wrote > On Fri, Jan 10, 2020 at 1:52 PM horrido < > horrido.hobbies@ > > wrote: > >> Offray Vladimir Luna CÃ¡rdenas-2 wrote >> > But I have not >> > being able to convince any of my coder friends to switch to Pharo >> > instead of C++, Java or Javacript, which by the way, is the language >> > they already know and use to put bread on the table on a daily basis. >> > >> > So I think that we deal with a paradox: while Smalltalk advocacy is >> > better suited for a Blue Ocean Strategy[2], exploring and implementing >> > new/emerging scenarios and markets, money is already mostly invested in >> > Red Oceans of constituted technologies and practices ecosystems. >> > Bridging both is pretty difficult. >> >> Yes, that is the principal obstacle and challenge. When I'm pushing >> Smalltalk, I mention the language's simplicity and conciseness, I >> mention the purity of the object-oriented model, I mention the >> built-in IDE, and so on. But the key advantage that I emphasize >> is *programmer productivity*. >> >> I realize it's hard to argue with the availability of jobs for Java, >> Python, >> JavaScript, etc. It's hard to argue with their rich ecosystems. It's >> hard to argue with the status quo of established code bases and >> IT infrastructures. But we have to make them believe that >> Smalltalk can cut their development time in half, if not better. >> >> What is it worth to a company to cut their development time in half? >> It means much lower development cost. It means much shorter >> "time to market." >> > > It also means much lower error rates. Capers Jones also review errors / > lines of code and Smalltalk was substantially better than the C derivative > languages. I don't recall the ration, but I think the Namcook report does > include it. > > Fewer errors means a higher ratio of time spent delivering functionality > and a better customer experience. (We can't do anything about bad design > and UX practices, of course and unfortunately. Although, I suspect without > evidence that Smalltalkers may do a better job of both.) > > >> Is this not worth investing time and energy in Smalltalk? Even if the >> job opportunities aren't there. Even if it means overhauling your >> IT infrastructure. >> >> The investment can lead to more users and more jobs. If they don't >> believe it, then we have failed. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Richard Sargent

On Fri, Jan 10, 2020 at 1:52 PM horrido <horrido.hobbies(a)gmail.com> wrote: > Offray Vladimir Luna CÃ¡rdenas-2 wrote > > But I have not > > being able to convince any of my coder friends to switch to Pharo > > instead of C++, Java or Javacript, which by the way, is the language > > they already know and use to put bread on the table on a daily basis. > > > > So I think that we deal with a paradox: while Smalltalk advocacy is > > better suited for a Blue Ocean Strategy[2], exploring and implementing > > new/emerging scenarios and markets, money is already mostly invested in > > Red Oceans of constituted technologies and practices ecosystems. > > Bridging both is pretty difficult. > > Yes, that is the principal obstacle and challenge. When I'm pushing > Smalltalk, I mention the language's simplicity and conciseness, I > mention the purity of the object-oriented model, I mention the > built-in IDE, and so on. But the key advantage that I emphasize > is *programmer productivity*. > > I realize it's hard to argue with the availability of jobs for Java, > Python, > JavaScript, etc. It's hard to argue with their rich ecosystems. It's > hard to argue with the status quo of established code bases and > IT infrastructures. But we have to make them believe that > Smalltalk can cut their development time in half, if not better. > > What is it worth to a company to cut their development time in half? > It means much lower development cost. It means much shorter > "time to market." > It also means much lower error rates. Capers Jones also review errors / lines of code and Smalltalk was substantially better than the C derivative languages. I don't recall the ration, but I think the Namcook report does include it. Fewer errors means a higher ratio of time spent delivering functionality and a better customer experience. (We can't do anything about bad design and UX practices, of course and unfortunately. Although, I suspect without evidence that Smalltalkers may do a better job of both.) > Is this not worth investing time and energy in Smalltalk? Even if the > job opportunities aren't there. Even if it means overhauling your > IT infrastructure. > > The investment can lead to more users and more jobs. If they don't > believe it, then we have failed. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 10, 2020