- Pharo-users - lists.pharo.org

Documentation system within Pharo

by Hilaire

Hi, Do we have any tool to browse external documentation from Pharo? I will be interested to give the option to DrGeo user to read programming documentation from Pharo (DrGeo doc use the texinfo format[1]). An Info reader will be even greater but I don't think we have one. Hilaire [1] https://www.gnu.org/software/texinfo/ -- Dr. Geo http://drgeo.eu

March 9, 2019

Pharo and FPGA

by Norbert Hartl

Iâm trying to collect information about programming in pharo for FPGA. The only things I found are around PharoROS like this [1]. If anyone has more information or is willing to talk about Iâm open ears. The background is that we did little things with the PharoThings toolkit and want to research which other combinations like Arduino, ESP32, FPGAs are there to be a good extensions to a Pi. Any hint is welcomed! Thanks, Norbert [1] http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20…

March 9, 2019

Re: [Pharo-users] pharo launcher chrash

by Roelof Wobben

March 9, 2019

Re: [Pharo-users] planet.smalltalk.org

by Sven Van Caekenberghe

Great find, thanks Pierce. > On 9 Mar 2019, at 13:41, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > I deleted the earlier thread from my mailbox, so starting a new one. > > By chance I found http://prog.vub.ac.be/~cderoove/planet/ which is the > Planet Smalltalk aggregator hosted by Coen De Roover. It is still > running and has the latest entries. > > Just a bit more work is needed to get planet.smalltalk.org to once again > point to this aggregator. > > Pierce > >

March 9, 2019

Re: [Pharo-users] pharo launcher chrash

by Ben Coman

The most I can tell is this seems significant... Stack backtrace: [65942944] signalSemaphore + 0xd64 in ProcessWrapperPlugin.DLL [659422CA] signalSemaphore + 0x6ea in ProcessWrapperPlugin.DLL Smalltalk stack dump: 0x11f8f84 M ProcessWrapper>finalize 0x8cb4fb0: a(n) ProcessWrapper 0x11f8fa0 M WeakFinalizerItem>finalizeValues 0x8c94148: a(n) WeakFinalizerItem Can you upload your PharoLauncher image somewhere for others to try - although the change in environment might disappear the error. cheers -ben On Sat, 9 Mar 2019 at 18:55, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > When starting up the launcher on Windows 10 I see a crash. > A dmp file is included. > > Roelof > >

March 9, 2019

planet.smalltalk.org

by Pierce Ng

I deleted the earlier thread from my mailbox, so starting a new one. By chance I found http://prog.vub.ac.be/~cderoove/planet/ which is the Planet Smalltalk aggregator hosted by Coen De Roover. It is still running and has the latest entries. Just a bit more work is needed to get planet.smalltalk.org to once again point to this aggregator. Pierce

March 9, 2019

Re: [Pharo-users] Pharo 7.0 image size

by Hilaire

Hi, Beside the browser windows, did you close all Transcript windows? Hilaire Le 08/03/2019 Ã 11:59, Trussardi Dario Romano a Ã©critÂ : > Ciao, > > this morning i started with an image of about 240 MB. > > I have 3 System Browser open ( for a long time ). -- Dr. Geo http://drgeo.eu

March 9, 2019

pharo launcher chrash

by Roelof Wobben

Hello, When starting up the launcher on Windows 10 I see a crash. A dmp file is included. Roelof

March 9, 2019

Re: [Pharo-users] FUEL serialization to a file

by Sven Van Caekenberghe

Konrad, You are raising many different points, I'll try to answer them. But first, it would help a lot that you give a self-contained reproducible snippet that raises your problem, like mine. I tried reproducing your failure but could not. Also note that all FUEL tests are green on a recent Pharo image. Regarding architecture and design. The idea of the 'new' streams is about simplification, streamlining and composability (if this is a real word) based on separation of concerns. It is my strong opinion that the current stream API is way to broad and complex. That is the main reason why it is not or should not be necessary to inherit from Stream. We want read and write streams to be separate, we want binary and character streams to be separate. Buffering, line end conversions, etc, should be pluggable. I remember that FLBufferedWriteStream was actual based on ZnBufferedWriteStream (one of FUEL's goals is performance), at a time when the primitive binary streams were unbuffered. That was years ago. Today, the high level binary streams are in principle buffered (ZnBufferedWriteStream) (although the raw ones still exist). It is thus no longer necessary to use FLBufferedWriteStream (although its API is slightly larger, it does a bit more than just buffer output). Now, looking at the specific selector you are talking about, #nextBytesPutAll: the way it is implemented and used, I can't understand why it even exists. Unless I am missing something it is the same as #nextPutAll: It is probably related to backwards or cross platform compatibility. Because today in Pharo, given a (buffered) binary stream, #nextPutAll: always takes bytes as argument. Another point is that right now, it seems double buffering is happening, which is not good. I guess we'll have to wait for one of the FUEL developers to chime in. All this being said, we are still in a transition period. Sven > On 9 Mar 2019, at 10:08, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Am 09.03.19 um 08:16 schrieb Konrad Hinsen: > >> In the second line, it sends nextBytesPutAll: to the unbuffered >> stream. Which should be fine if it inherits from Stream. But >> ZnBufferedWriteStream does not inherit from Stream. > > The fix I found is simple, but I don't understand the whole system well enough to be sure that it doesn't cause trouble elsewhere. I added the method ZnBufferedWriteStream >> nextBytesPutAll: > > nextBytesPutAll: aCollection > self nextPutAll: aCollection > > and all my problems are gone. > > Konrad. >

March 9, 2019

Pharo OSX bundle in Mojave - how to sign ? (Was Re: OS X bundle, some progress)

by CÃ©drick BÃ©ler

Hi, I tried a bit more to make DrGeo bundle works. I have Mojave (10.14) and the problem of corrupted files seems to come from Gatekeeper with prevent unsigned applications (from unknot developper) to open. Gatekeeper can be temporary stopped and then the bundle work, even when Gatekeeper is reactivated. But clearly, this is not a friendly user way of installing DrGeo. So I guess the actual (old ?) bundle procedure doesnât fit Apple politic on application security. I'm pretty sure PharoLauncher faced this already. So my question is: - how to make a signed bundle for OSX ? â do we need a real developer account ? Iâve a free one and access to a paid one. Can we do it with a general Â« pharaoh Â» account like for Pharo-Launcher ? Cheers, CÃ©drick > Le 3 mars 2019 Ã 15:59, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > > Hi Hilaire, > > On Sun, 3 Mar 2019 at 09:31, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> One useful information will be to know where stdout file is created by >> default? >> >> VM, image, home, folder, ... > > On linux and MacOS the three stdio streams exist for every process: > stdin, stdout & stderr. > > If you're starting a process from the shell, they are normally > attached to the terminal (unless you redirect them). I don't know > what happens on MacOS when you start a process from the GUI. > > >> Obviously there is situation with problem creating stdout files. > > There's lots of MacOS users here who aren't having this problem, so my > first guess is that there's something about your environment that is > causing the issue. > > Can you provide the text from System -> System Reporter -> VM General? > > Cheers, > Alistair > > >> Can it be shutdown? >> >> For the record, the error is REPEATABLE, Pharo started from the CLI or >> from an installed Application. Once the image started: >> >> error with stdout does not exist, force recursive file creation, filename "stdout" >> >> This occures with stock OS X 32bits VM and Image. >> >> Any one willing to do serious deliverable Pharo Application with Mac >> will be hit by this error. Is OS X making situation more difficult? >> >> Hilaire >> >> Le 01/03/2019 Ã 23:19, Hilaire a Ã©crit : >> Hi, >>> I did some progress on the Dr.Geo bundle for OS X. >>> >>> The Mac admin of my school told me to download from Safari and >>> authorized the drgeo.eu web site (not sure what this exactly does), then >>> we installed the DrGeo.app at the Application location. >>> >>> DrGeo started fine but emit a startup error at the image level, related >>> to stdout. It looks like a stdout file can not be created. The stack is >>> enclosed here. When looking at the execution stack, I could not >>> determine (I have to go teaching) where the image wants to create this >>> stdout file. >>> >>> Any idea or opinion on this stdout matter? >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

March 9, 2019