- Pharo-users - lists.pharo.org

Re: [Pharo-users] Embedded PDF viewer?

by K K Subbu

On Monday 13 November 2017 09:50 AM, Ben Coman wrote: > I've managed to build PDFium into a shared library on Ubuntu 16.04. > (I'll announce a blog post on this later.) > Now I'm considering the best bitmap format to bring the rendered page > back into Pharo. Have you considered importing PDFs as a sequence of compressed PNGs into Pharo? If you not interested in twiddling pixels in the imported PDFs, perhaps PNG may be sufficient. They take up lesser space and easier to move around or re-export. Regards .. Subbu

Nov. 13, 2017

Re: [Pharo-users] Embedded PDF viewer?

by Ben Coman

I've managed to build PDFium into a shared library on Ubuntu 16.04. (I'll announce a blog post on this later.) Now I'm considering the best bitmap format to bring the rendered page back into Pharo. I'm seeking advise on... Q1. Looking at the two significant bitmap creation functions below from the C header file, which of PDFium's bitmap formats is the best match for Pharo? // Gray scale bitmap, one byte per pixel. #define FPDFBitmap_Gray 1 // 3 bytes per pixel, byte order: blue, green, red. #define FPDFBitmap_BGR 2 // 4 bytes per pixel, byte order: blue, green, red, unused. #define FPDFBitmap_BGRx 3 // 4 bytes per pixel, byte order: blue, green, red, alpha. #define FPDFBitmap_BGRA 4 typedef void* FPDF_BITMAP; // Function: FPDFBitmap_CreateEx // Create a device independent bitmap (FXDIB) // Parameters: // width - The number of pixels in width for the bitmap. // Must be greater than 0. // height - The number of pixels in height for the bitmap. // Must be greater than 0. // format - A number indicating for bitmap format, as defined // above. // first_scan - A pointer to the first byte of the first line if // using an external buffer. If this parameter is NULL, // then the a new buffer will be created. // stride - Number of bytes for each scan line, for external // buffer only. // Return value: // The bitmap handle, or NULL if parameter error or out of memory. // Comments: // Similar to FPDFBitmap_Create function, but allows for more formats // and an external buffer is supported. The bitmap created by this // function can be used in any place that a FPDF_BITMAP handle is // required. // // If an external buffer is used, then the application should destroy // the buffer by itself. FPDFBitmap_Destroy function will not destroy // the buffer. FPDF_BITMAP FPDFBitmap_CreateEx( int width, int height, int format, void* first_scan, int stride); // Function: FPDFBitmap_Create // Create a device independent bitmap (FXDIB). // Parameters: // width - The number of pixels in width for the bitmap. // Must be greater than 0. // height - The number of pixels in height for the bitmap. // Must be greater than 0. // alpha - A flag indicating whether the alpha channel is used. // Non-zero for using alpha, zero for not using. // Return value: // The created bitmap handle, or NULL if a parameter error or out of // memory. // Comments: // The bitmap always uses 4 bytes per pixel. The first byte is always // double word aligned. // // The byte order is BGRx (the last byte unused if no alpha channel) or // BGRA. // // The pixels in a horizontal line are stored side by side, with the // left most pixel stored first (with lower memory address). // Each line uses width * 4 bytes. // // Lines are stored one after another, with the top most line stored // first. There is no gap between adjacent lines. // // This function allocates enough memory for holding all pixels in the // bitmap, but it doesn't initialize the buffer. Applications can use // FPDFBitmap_FillRect to fill the bitmap using any color. FPDF_BITMAP FPDFBitmap_Create( int width, int height, int alpha); // Function: FPDFBitmap_Destroy // Destroy a bitmap and release all related buffers. // Parameters: // bitmap - Handle to the bitmap. Returned by FPDFBitmap_Create. // Return value: // None. // Comments: // This function will not destroy any external buffers provided when // the bitmap was created. void FPDFBitmap_Destroy(FPDF_BITMAP bitmap); Pharo's relevant class comments are... * Bitmap - My instances provide contiguous storage of bits, primarily to hold the graphical data of Forms. Forms and their subclasses provide the additional structural information as to how the bits should be interpreted in two dimensions. * Form - A rectangular array of pixels, used for holding images. All pictures, including character images are Forms. The depth of a Form is how many bits are used to specify the color at each pixel. The actual bits are held in a Bitmap, whose internal structure is different at each depth. The supported depths (in bits) are 1, 2, 4, 8, 16, and 32. The number of actual colors at these depths are: 2, 4, 16, 256, 32768, and 16 million. Forms are indexed starting at 0 instead of 1; thus, the top-left pixel of a Form has coordinates 0@0. Forms are combined using BitBlt. See the comment in class BitBlt. Forms that repeat many times to fill a large destination are InfiniteForms. So it seems Bitmap is agnostic to the format stored inside it, and it is Form that interprets the bitmap format. A 32 bit depth Form seems an obvious choice, but I'm not sure about the alpha options. Q2. Tips on how to display such a bitmap in Pharo? I found this example... | extent form ptr | extent := 400@300. form := ExternalForm extent: extent depth: 32. ptr := ExternalAddress gcallocate: (extent x * extent y * 4). form setManualSurfacePointer: ptr. "insert here call to PDFium to render page to bitmap" Display displayScaledOn: form. form displayAt: 0@0. form destroySurface. where in my case I guess the "ptr:=" line might be replaced by... ptr := ffi_FPDFBitmap_Create width: extent x height: extent y alpha: 0. or... ptr := ffi_FPDFBitmap_CreateEx width: extent x height: extent y format: ?? first_scan: 0 stride: 0 but it seems ExternalForm doesn't exist in Pharo 6. ExternalForm seems to have been taken over by OSSDL2ExternalForm... ??? * OSSDL2ExternalForm - An ExternalForm is a specialized Form whose pixel-data is stored in memory that the user provides a pointer to. This can simply be memory on the C heap, or (the motivating use-case...) it can be a pointer that is temporarily "mapped" from GPU memory by an API such as OpenCL. IMPORTANT: Moved form FFI to SDL2 because is not needed there anymore but OSWindow-SDL2 package uses it. The user is responsible for both releasing the image-memory, as well as destroying the surface handle (perhaps the latter should be handled by automatic finalization). Q3a. Are there any general guiding FFI principals whether its better to use memory allocated by the library, or memory allocated by Pharo? Perhaps instead I should use... pharo_allocated := ExternalAddress gcallocate: (extent x * extent y * 4). ptr := ffi_FPDFBitmap_CreateEx width: extent x height: extent y format: ?? first_scan: pharo_allocated stride: ?? Q3b. Is it possible/advisable to pin a Bitmap and pass it to an external library? Maybe it would be preferable to do something like... aBitmap := Bitmap new: (extent x * extent y * 4). ptr := ffi_FPDFBitmap_CreateEx width: extent x height: extent y format: ?? first_scan: aBitmap pinnedAddress stride: ?? cheers -ben On Sun, Nov 5, 2017 at 11:24 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello Ben, > UFFI does not allow you to call static libraries. Static libraries are > not executable per se, they need to be linked in another program. > As I know, the only way of using an static library from Pharo is to: > - Build a plugin that wraps it. > - Build a DLL exposing all the functions in the library and then they > are used through UFFI. > > The second option is the easiest to me, but it depends how the library is > built up. For example, if the library uses a lot of compile time code > generation (like macros or templates) making a generic DLL is not so easy. > > I think it is better to see if not other project has already tackle this > problem when using the desired static library. > > Cheers, > Pablo > > On Sun, Nov 5, 2017 at 1:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I'm looking into calling PDFium from Pharo via FFI. >> Currently I'm stalled a bit since it doesn't have a shared-library target. >> >> If you consider access to such a library would be useful to the >> community, >> please take a few moments to star this issue... >> https://bugs.chromium.org/p/pdfium/issues/detail?id=826 >> >> cheers -ben >> >> >> P.S. Can anyone comment on calling into a static library via FFI? >> >> >> >> On Wed, Oct 11, 2017 at 2:05 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Wed, Oct 11, 2017 at 2:03 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> > On Tue, Oct 10, 2017 at 8:58 PM, Manuel Leuenberger >>>> > <leuenberger(a)inf.unibe.ch> wrote: >>>> > > Hi, >>>> > > >>>> > > I want to view a PDF within Pharo. I found that Athens has a PDF >>>> canvas, but I have no idea how to use it. Is there a way to view a PDF >>>> within Pharo, so that I can scroll, zoom, click links etc. in the PDF? >>>> > > >>>> > > Cheers, >>>> > > Manuel >>>> >>>> >>>> On Wed, Oct 11, 2017 at 3:04 AM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> > >>>> > Hi manuel >>>> > >>>> > So far I do not know if we have this is Pharo. >>>> > I imagine that we would have to build a renderer once we will have the >>>> > PDF reader from Christian library. >>>> > >>>> > Stef >>>> >>>> >>> [Edit: Update license link] >>> >>> >>>> A renderer will have great synergy with PDFTalk, but I think a proof of >>>> concept can be done independently. >>>> I've been poking at this topic for a while looking for options. >>>> Coincidentally a couple of days I discovered the PDFium library. >>>> I haven't had time yet to give it a run, but it seems a good candidate >>>> since... >>>> * Its a successful commercial product by Foxit built into Chrome >>>> converted to open source with Google's backing for use in Chromium >>>> https://www.foxitsoftware.com/company/press.php?id=305 >>>> * Its license is BSD style >>>> *https://github.com/hfiguiere/pdfium/blob/master/LICENSE >>>> <https://github.com/hfiguiere/pdfium/blob/master/LICENSE>* >>>> * Although written in C++ it has a C interface >>>> https://github.com/hfiguiere/pdfium/blob/master/public/fpdfview.h >>>> * Search here on " Function: " to skim through >>>> * Proof of concept seems to only need these key functions... >>>> * void FPDF_RenderPageBitmap( FPDF_BITMAP bitmap,FPDF_PAGE >>>> page, ... ) >>>> * FPDF_BITMAP FPDFBitmap_Create( int width, int height, >>>> int alpha); >>>> * FPDF_PAGE FPDF_LoadPage ( FPDF_DOCUMENT document, int >>>> page_index ) >>>> * FPDF_DOCUMENT FPDF_LoadMemDocument ( const void* >>>> data_buf ... ) >>>> * void FPDF_InitLibrary () >>>> * Has a concise getting started for POC... >>>> https://github.com/hfiguiere/pdfium/blob/master/docs/getting >>>> -started.md >>>> * Maybe useful fork with V8 disabled by default >>>> https://github.com/klokantech/pdfium >>>> * Master repo here >>>> https://pdfium.googlesource.com/pdfium/ >>>> >>>> So Pharo might load a PDF file into a ByteArray, pass that to >>>> FPDF_LoadMemDocument() & FPDF_LoadPage(), >>>> then get a bitmap back from FPDFBitmap_Create() & >>>> FPDF_RenderPageBitmap() and display the result in a Pharo window. >>>> >>>> The rest of this week I'm working 12 hour days on a mine site. I could >>>> try it out once I'm home, but in the meantime is anyone else keen to try >>>> it? >>>> >>>> cheers -ben >>>> >>> >>> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

Nov. 13, 2017

Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 102

by ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²

Thanks Stef, also thank all of you for your support. It is very important to me and shows that Pharo is really in progress. I didn't ever complained - i just asked simple questions on topics i don't know. And i get lot's of answers to make some decisions. I understand where to get information and what are the prospects of using Pharo. I came to Pharo looking for appropreate Smalltalk implementation after Cincom denied access to its PUL version of VW. I found Pharo as the most advanced but it also has its disadvantages. My project is a desktop GUI application with some hacks with saving data to\from image on-the-fly and lots of GUI dialogs + complex custom GUI control. It is a kind of personal data\information manager. I'm very lazy and i like to read rich manuals more than to investigate complex code. I think it is much more natural when you don't need to study the whole system before you can do simple things. For example, i don't want to waste lots of time to understand what is the difference between bloc and spec, i want to read few paragraphs of manual and look into some class comments, and than do the task. So i think you made a great progress in this direction with Spec - the manual is very clear and allows developing UI with minimal efforts - just to read some abstracts from manual. But in some areas i need to ask somebody who knows much more than i do. And i don't think there could be "dumb questions", but a _lack_of_information_. Also, when something is evident to one - it could be not so evident to another person. That is why i ask such simple things. Also i became accustomed to the situation when platform implements some basic stuff like i wrote earlier (UI tools, i18n, deployment, etc) and it was not evident to me that such modern system as Pharo cannot do it, so i asked about it. I have seen that Pharo is powerful system but i need to decide what to do: 1) create some personal solution based on different answers above. Lots of code investigations, coding and debugging (fixing existed bugs that are not on pharo roadmap). 2) wait until some release of Pharo fix bugs with non-latin paths, implement minimal level of integrated with UI framework i18n and deployment\packaging of applications. Every software developer tries to find the simplest solution for his task. I apologized if i said something wrong, i really didn't want to hurt somebody's feelings. Vikenti. > > We are focused on deployment but not the same way. > We are the first system that bootstrap a core and can load > dependencies on this core. > We have a dependency analyser that is really advanced since it can > check that you have message that are not in extension > of packages that you use. > In January I hope that we will start packaging Applications (versus > packaging code), so that people can deploy > desktop applications more easily. > > Now if people like vikenti wants our support. They should learn how to > engage a discussion with us and not > just complain :) > > Stef >

Nov. 13, 2017

Re: [Pharo-users] Open Debugger, Save and Quit

by Sean P. DeNigris

Sean P. DeNigris wrote > In a headless image, I'd like to do the following: if there's any error, > arrange to have a debugger open on the next (headful) launch, and then > save > and quit. Bump :) I can't believe no one knows how to do this! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 12, 2017

Re: [Pharo-users] Pharo-Chrome (was: Soup bug(fix))

by Alistair Grant

Hi Sean, Thanks for your feedback! (responses below) On 12 November 2017 at 18:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote >> https://github.com/akgrant43/Pharo-Chrome > > Wow, that was a wild ride! Sorry about that. > Lessons learned along the way: > 1. On a Mac, to use the snazzy `chrome` terminal command referenced all over > the place in the docs, you must first `alias chrome="/Applications/Google\ > Chrome.app/Contents/MacOS/Google\ Chrome"` I'm an Ubuntu Linux user, however if you look at OSXChromePlatform class>>defaultExecutableLocation you can see that is where it should be looking for the exe, so the alias shouldn't really be necessary. Torsten wrote this, so maybe has more insight. > 2. Chrome must be started with certain flags: `chrome > --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is > needed, but `#get:` seemed to hang before using; reference > https://developers.google.com/web/updates/2017/04/headless-chrome) I've been using this without headless mode. I'll add a headless flag that also disables the gpu. > 3. Beacon has renamed InMemoryLogger to MemoryLogger > 4. I guess Beacon has renamed `#log` to `#emit` Sorry about that. I didn't realise that the Pharo-Chrome baseline is loading Beacon stable while my install script upgrades it to #development. #development is more recent, so I'll update the baseline. > 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` was > nil and also #sigterm seemed not to be defined anywhere in the image. I'm > not sure what the issue is there. chromeProcess is set in GoogleChrome>>openURL:. Can you give me a small example that demonstrates the problem? #sigterm is implemented by OSSUnixSubprocess, which is what I ultimately use to launch the Chrome process on Ubuntu. But... this will be broken on Mac at the moment because the current method of launching chrome doesn't keep track of the process, so doesn't support #sigterm. Do you know if OSSUnixSubprocess works on Mac? If it does, I can update the code (but not test it :-(). > Pull request issued for #3 & #4. Once I update the baseline this shouldn't be required. > Also, I'm not sure what platforms you > support, but you may want to tag the example methods with <gtExample> or > similar so that they are runnable from the browser and open an inspector if > there is an interesting return value. Good idea, I'll do this. I'm also making a few other changes: 1. Add an #extractTables method that searches through the page and returns an array of rows for each table it finds in the page (something that can easily be loaded in to DataFrame using #fromRows:, but I don't want to make Pharo-Chrome dependent on DataFrame at the moment). Most of the time I use Pharo-Chrome it is extracting data from tables. 2. I don't know of any reliable way to tell when a page has loaded since there can always be javascript that periodically updates the page. At the moment it waits until the page hasn't changed for a configurable amount of time. I'm planning to add a check for specific content to determine if the page is considered loaded. 3. Add some documentation to the readme :-) > ----- > Cheers, > Sean I'll let you know when I have a new version available (hopefully in the next few days). Thanks again, Alistair

Nov. 12, 2017

Re: [Pharo-users] I18n in pharo

by Offray Vladimir Luna CÃ¡rdenas

Thanks Stef, Spec/GT-Tools bridge by Johan Fabry is working well for me and is what has enabled Grafoscopio as, essentially, a notebook of embedded playgrounds inside a tree like document. I confident that the infrastructure will mature even more to allow more Spec+GT magic. Soon I hope to share with the community more Grafoscopio books, which are my take on some Pharo powered books, particularly Agile Visualization. Cheers, Offray On 12/11/17 07:06, Stephane Ducasse wrote: > Offray > > Pavel and me have been working to clean and enhance Spec aspects. We > are getting slowly but we will continue.Â > I want to support menu in a much better way (declarative).Â > Peter rewrote the Spec Interpreter and I hope that it will finish it, > else we will have to do it because the code is "suboptimal". > > > Stef > > On Sun, Nov 12, 2017 at 12:59 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Thanks for the diagram Aliaksei. It helps to understand the Pharo > buildings blocks. Where Spec would be located there? > > Cheers, > > Offray > > > On 11/11/17 15:56, Aliaksei Syrel wrote: >> Hi Hilaire, >> >> About my perception on Pharo, from a distant POV, I see >> parallel/overlapping/contiguous layers like Morphic, Athens, >> Sparta, Bloc, Brick, Spec, GT, >> >> >> Could you, please, explain in a bit more detail why do you think >> that Sparta, Bloc, Brick and GT are overlapping layers? >> >> In attachment you can find a layered architecture diagram that >> explains how those technologies are stacked _from our_ point of >> view :) >> Inline images 1 >> Cheers, >> Alex >> >> On 11 November 2017 at 21:48, stephan <stephan(a)stack.nl >> <mailto:stephan@stack.nl>> wrote: >> >> On 11-11-17 21:18, H. Hirzel wrote: >> >> On 11/11/17, stephan <stephan(a)stack.nl >> <mailto:stephan@stack.nl>> wrote: >> >> On 10-11-17 12:23, CÃ©drick BÃ©ler wrote: >> >> Plus I have the impression Morphic mess is about >> to be solved. >> >> >> There is still an awful lot of essential complexity >> in beautiful >> graphics and typography that is not going away. >> Microsoft Word still >> cannot layout a paragraph of text after 34 years of >> development >> >> >> Can you point to an example of this? >> >> >> https://en.wikipedia.org/wiki/Microtypography >> <https://en.wikipedia.org/wiki/Microtypography> >> >> Stephan >> >> >> > >

Nov. 12, 2017

FW: deploying Pharo applications

by Andrew Glynn

The issue probably stems from not using Pharo by choice. Apparently he canât continue to use VW for political reasons, and is annoyed at having to port everything to an open source Smalltalk. Iâd probably be annoyed myself if I had to port something I did 15 or 20 years ago in VisualAge or IBM Smalltalk, whatever I had to port it to. Iâve only had to port one project from Pharo to an IBM Smalltalk server process, so that it could run on a 128 thread UltraSparc. If I were any use writing compilers I could have ported Pharo itself, unfortunately Iâm not. The options thatâve been given are workable. The advantages of Pharo are not going to be obvious if youâre only porting code written elsewhere, while differences are going to be right in your face. Andrew From: Stephane Ducasse Sent: Sunday, November 12, 2017 10:05 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94 Joachim We are focused on deployment but not the same way. We are the first system that bootstrap a core and can load dependencies on this core. We have a dependency analyser that is really advanced since it can check that you have message that are not in extension of packages that you use. In January I hope that we will start packaging Applications (versus packaging code), so that people can deploy desktop applications more easily. Now if people like vikenti wants our support. They should learn how to engage a discussion with us and not just complain :) Stef On Sun, Nov 12, 2017 at 6:02 AM, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > Am 11.11.17 um 22:29 schrieb ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²: > > Vikenti, >> >> And also i mean some simple and understandable deployment tool (as in >> Cincom VW exists) but not manual-written bash scripts.Â This tool asks me >> what class\accessor send open message, asks what to strip and how to pack my >> image. Few simple steps and i have perfectly cleaned minimal image with all >> image started methods tuned to load necessary class. It's really cool stuff. >> It's a pity, my low-level SmallTalk knowledge (VW + Pharo) is not enough to >> port this tool or create the new one. > > just out of curiosity and following my first reflex: if VisualWorks offers > most of what you need and is essentially what you want - why do you want to > switch to Pharo? > > This is not intended to be offensive or provoking. I just wonder if an open > source project is the right thing for you. Pharo is emerging and has quite > some pace doing so. This is both good and bad - at many levels. Commercial > offerings may be a lot slower and thus less of a "moving target" (not sure I > am citing you, but I know I read this in one of the threads about the > current state of Pharo just these days), but they are pretty much focussed > on issues like deployment and stable APIs. > > > Joachim > > >

Nov. 12, 2017

Re: [Pharo-users] deploying Pharo applications

by Andrew Glynn

I think the issue stems from not using Pharo by choice. Apparently he canât continue to use VW for political reasons, and is annoyed at having to port everything to an open source Smalltalk. Iâd probably be annoyed myself if I had to port something I did 15 or 20 years ago in VisualAge or IBM Smalltalk, whatever I had to port it to. Iâve only had to port one project from Pharo to an IBM Smalltalk server process, so that it could run on a 128 thread UltraSparc. If I were any use writing compilers I could have ported Pharo itself, unfortunately Iâm not. The options thatâve been given are workable. The advantages of Pharo are not going to be obvious if youâre only porting code written elsewhere, while differences are going to be right in your face. Andrew From: Stephane Ducasse Sent: Sunday, November 12, 2017 10:05 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94 Joachim We are focused on deployment but not the same way. We are the first system that bootstrap a core and can load dependencies on this core. We have a dependency analyser that is really advanced since it can check that you have message that are not in extension of packages that you use. In January I hope that we will start packaging Applications (versus packaging code), so that people can deploy desktop applications more easily. Now if people like vikenti wants our support. They should learn how to engage a discussion with us and not just complain :) Stef On Sun, Nov 12, 2017 at 6:02 AM, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > Am 11.11.17 um 22:29 schrieb ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²: > > Vikenti, >> >> And also i mean some simple and understandable deployment tool (as in >> Cincom VW exists) but not manual-written bash scripts. This tool asks me >> what class\accessor send open message, asks what to strip and how to pack my >> image. Few simple steps and i have perfectly cleaned minimal image with all >> image started methods tuned to load necessary class. It's really cool stuff. >> It's a pity, my low-level SmallTalk knowledge (VW + Pharo) is not enough to >> port this tool or create the new one. > > just out of curiosity and following my first reflex: if VisualWorks offers > most of what you need and is essentially what you want - why do you want to > switch to Pharo? > > This is not intended to be offensive or provoking. I just wonder if an open > source project is the right thing for you. Pharo is emerging and has quite > some pace doing so. This is both good and bad - at many levels. Commercial > offerings may be a lot slower and thus less of a "moving target" (not sure I > am citing you, but I know I read this in one of the threads about the > current state of Pharo just these days), but they are pretty much focussed > on issues like deployment and stable APIs. > > > Joachim > > >

Nov. 12, 2017

Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 94

by Sean P. DeNigris

jtuchel wrote > I sometimes get the impression Pharo is moving so fast I > just can't follow. Don't worry. I use Pharo every day and sometimes feel the same way! I just hang on and do my best because I know it's all for a good reason. I accept the pain in the short-term because the projects I /really/ want to do depend on these critical improvements. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 12, 2017

Re: [Pharo-users] Soup bug(fix)

by Sean P. DeNigris

Alistair Grant wrote > https://github.com/akgrant43/Pharo-Chrome Wow, that was a wild ride! Lessons learned along the way: 1. On a Mac, to use the snazzy `chrome` terminal command referenced all over the place in the docs, you must first `alias chrome="/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome"` 2. Chrome must be started with certain flags: `chrome --remote-debugging-port=9222 --disable-gpu` (not sure if the last flag is needed, but `#get:` seemed to hang before using; reference https://developers.google.com/web/updates/2017/04/headless-chrome) 3. Beacon has renamed InMemoryLogger to MemoryLogger 4. I guess Beacon has renamed `#log` to `#emit` 5. I had to comment out `chromeProcess sigterm.` because `chromeProcess` was nil and also #sigterm seemed not to be defined anywhere in the image. I'm not sure what the issue is there. Pull request issued for #3 & #4. Also, I'm not sure what platforms you support, but you may want to tag the example methods with <gtExample> or similar so that they are runnable from the browser and open an inspector if there is an interesting return value. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 12, 2017