November 2016 - Pharo-users

Re: [Pharo-users] Spec: Setting rows height of a pictures list
by stepharo Nov. 8, 2016

Nov. 8, 2016

Matteo your emails format looks quite strange... Le 8/11/16 Ã 14:27, Matteo via Pharo-users a Ã©crit : > I think the adaptor will called "MorphicImageFastTableAdaptor", and > the model "ImageFastTableAdapter". > > In the package "Spec-MorphicAdapters", the "MorphicFastTableAdapter" > uses an object "FTPluggableIconListMorphAdaptor". I would say yes because as you I find this suboptimal. Now may be it was created like that because of incompatibilities between uses of PluggableIconListMorph (RIP) and FT. Nothing is simple when you have legacy and different interaction protocol > > Could the "MorphicImageFastTableAdaptor" use directly a "FTTableMorph" > object, instead of creating "pluggable" adapter? Could you give a try and let us know. I' super hyper fuulllllll (tomorrow 6 hours teaching). > > cheers, > Matteo

1 0

[ann] petitparser2
by Tudor Girba Nov. 8, 2016

Nov. 8, 2016

Hi, I am happy to announce the availability of PetitParser2, a wonderful redesign of the original PetitParser developed by Jan KurÅ¡. https://github.com/kursjan/petitparser2 Highlights: - it introduces the compiler facility that speeds up parsers by a factor of ~2-5x - it introduces the possibility of parsing streams without having them in memory - it comes with a new structure internally that makes it more flexible - it introduces asPParser (not a typo) to be able to have the new version working in parallel with the classic asParser The version is already present in the latest Moose 6.1 in parallel with PetitParser. Also, several of the parsers that are shipping with PetitParser were already copied to PetitParser2 as well. You can find more details here: http://www.humane-assessment.com/blog/introducing-petitparser2/ Some more documentation will follow. I think Jan did a wonderful job and the result is quite exciting. Please take a look and let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

1 0

Re: [Pharo-users] Spec: Setting rows height of a pictures list
by stepharo Nov. 8, 2016

Nov. 8, 2016

Le 5/11/16 Ã 15:59, Matteo via Pharo-users a Ã©crit : > > Re: [Pharo-users] Spec: Setting rows height of a pictures list.eml > > Sujet : > Re: [Pharo-users] Spec: Setting rows height of a pictures list > De : > Matteo <matteob8(a)yahoo.it> > Date : > 5/11/16 15:53 > > Pour : > Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Hi Nicolai, > I think it would be great to have a specific ListModel for pictures, > like the IconListModel. > > Do you know if there's already someone working on a "picture" ListModel? Not that I know. > Could I try to implement it, and its morphic adapter? Sure! Now pay attention that it is probably better to use FastTable on the morphic level. > > Thanks, > Matteo > > On 31/10/16 15:20, Nicol

2 1

ZÃ¼rich Smalltalk Meetup Reminder
by jtuchel＠objektfabrik.de Nov. 8, 2016

Nov. 8, 2016

Hi there, in case you forgot about it: The ZÃ¼rich Smalltalkers will meet tonight at 7pm for another meetup. There will be at least 2 presentations: * Reza will show Web Pontoon * Michal will show hs current work on a new Pharo-Gemstone/S-bridge * who knows, maybe you feel like demoing tonight? This time, we meet at a nice conference room first and go for drinks and dinner later. Here is where you can get in touch with Smalltalkers of all flavors, colors, shapes, sizes, ages and genders: Alpha Sprachwelt AG <http://alphasprachwelt.ch/kontakt.html> Stadelhoferstrasse 10 â Room 23 â 8001 ZÃ¼rich See the location on a map <https://wego.here.com/directions/publicTransport/Alpha-Sprachstudio,-Stadel…> So feel free to come and chat a little or discuss your current work. Joachim (I won't be able to attend, unfortunately. The best thing I could do today would be to share a few virusses with you and help you get a few days off. But I am eager to hear if this new format in a meeting room works well. Have fun!!!)

1 0

Linking issues to versions (bug analysis) in pharo
by Yuriy Tymchuk Nov. 8, 2016

Nov. 8, 2016

Hi, has anybody done anything with bug analysis in Pharo? I know that the most common approach is to see in which version an issue was closed and what code was changed and when was that code introduced and as the result you have lifespans of bugs. Other suggestions are also welcome :) Uko

1 0

[UFFI] How to get a string from the a void pointer
by Dimitris Chloupis Nov. 7, 2016

Nov. 7, 2016

So I managed to port all C++ functions to pharo, which basically includes the following Not full definition of function open() lseek() close() mmap() I have tested them all, they all return proper values from inside Pharo and Pharo does not crash. it seems also that mmap works because it returns a void pointer as it should. This pointer points to the shared memory where I have put the string "hello" from another C++ program that has shared the memory . So how can from Pharo take the void pointer "(void*)@ 16rFFFFFFFF" and retrieve the string "hello" that it points to ? Essentially I want to dereference the pointer I tried to send the message fromCString to the void pointer (ExternalData) but it crashed Pharo. Another question, is it possible to cast a pointer ? (I do this with C++ programm) so can I cast from pharo the void pointer to a string pointer ? I have also no idea if the void pointer points to a proper memory address , the documentation says that all pointers live in head but I have no way to confirm this. I am so close to sharing memory between Pharo and C++ that I can smell it :D

1 1

Pharo desktop UI
by vikenti Nov. 7, 2016

Nov. 7, 2016

Hello, i'm newbie in Pharo, converted from Visual Works which is quite different from Pharo Smalltalk. I started to port my application (i've been working on for about three years) from VW (because of new personal user licensing limitations of Visual Works), but i have to solve some problems and need your advice. These ase some of the most important problems: 1. I need to rewrite the whole GUI from scratch. What UI framework to choose and where to get documentation? Please, don't send me to research code examples instead of docs - i do this during whole last week. The example should be complete and simple: one task - one example, all examples i've seen are either not applicable to real life or too complicated to understand. - I need simple window with menu (how to attach menu items to menu handlers???? - no answer in examples) - Toolbar with icons (how????????) - components (as i understand - Morphic subclasses, it is the simplest part) - when window opens i need handler to do some setup actions. Handler should fire after UI is built and my app's window is opened (how?????) - i need another handler, which fires when you try to close Pharo or application's window. Handler must check whether to close window or not and do allow or not to close my application. - how to programmatically close window?????? 2. The next task is to do some work on image load (i mean pharo image). I need some handler which fires immediately after image is loaded. How to include my handler in this chain???? My app saves data into the image so i need to manage this and auto-load _my_ application after startup. 3. How to drag-n-drop from the host operation system into pharo application and vice versa? I need to drag-n-drop a list of files from\to file browser. 4. Application deployment. How to strip the unnecessary code from the image? I've heard there is "small image" to add all-i-need-to-run. Where i can download it and how to use it???? -- View this message in context: http://forum.world.st/Pharo-desktop-UI-tp4921212.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

6 16

Re: [Pharo-users] Speed up JPG images loading
by Sven Van Caekenberghe Nov. 7, 2016

Nov. 7, 2016

Hi Matteo, > On 5 Nov 2016, at 16:11, Matteo via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Matteo <matteob8(a)yahoo.it> > Subject: Speed up JPG images loading > Date: 5 November 2016 at 16:10:45 GMT+1 > To: "Pharo is welcome (ML)" <pharo-users(a)lists.pharo.org> > > > Dears, > I'm loading a lot of pictures (70) through the method > "ImageReadWriter>>formFromFileNamed:". > The method is very slow, with images bigger than 5MB. > > Is there a way to improve the pictures speed loading? > > > Thanks > Matteo I think we'll need more details. Here is what I tried: (ImageReadWriter formFromFileNamed: '/Users/sven/Desktop/audio359-main-1600.jpg') asMorph openInWindow. This is a 319K JPG 1600x2263 (Form's Bitmap length is 3620800). [ ImageReadWriter formFromFileNamed: '/Users/sven/Desktop/audio359-main-1600.jpg' ] bench. '2.788 per second' 2 to 3 per second is not very fast, but you create forms of 3.5M - In this case the PluginBasedJPEGReadWriter is used, which should be faster then any of the other formats. What you can do is store a FUEL version of the Form on file, that will be (much) faster (but much larger, it is basically a non-compressed version). Sven

2 2

About balkanisation
by stepharo Nov. 7, 2016

Nov. 7, 2016

Hi I would like that you think a bit about our community and that there is a value in using common tools to share and develop common libraries. Because to me it feels like we are getting balkanize. It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool features), but I would like to ask especially people building libraries to pay attention that it is important that other people can contribute back easily and that there is an easy way to load/contribute. Today I experienced Bloc - I cannot load code and I cannot contribute. - I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day. Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts. We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from what I can see. So pay attention about the decision you take. Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming about that) and that we are doing experiments (Guille is managing the bootstrap in github). Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget that it is called pillar-markup), what will we do. So we need an infrastructure to handle this and christophe is working on this. I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices. Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community. Stef

8 22

Iceberg/GitFileTree (was Re: about balkanisation)
by Thierry Goubier Nov. 7, 2016

Nov. 7, 2016

Nicolas, I changed the subject, it seems appropriate. 2016-11-07 16:56 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > 2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >>> The problem I found is that in order to recreate sequential numbers, you >>> have to load all commits into the image. >>> >> >> Why? GitFileTree doesn't need to do that at all! Well, you know the code: >> it just ask git log to rebuild the parent / child relations for a package >> directory, and that is all... Then, like a mcz, the package isn't loaded >> into the image unless you select it in the GUI. So why did you need to load >> all the commits? >> >> Well, at the beginning, I was trying to read all the filetree metadata >> stored in the repository to build the versions as if it was mczs... and >> that was a really bad idea (slow parser for version files, hundred of files >> to scan, many files were even unreadable/broken by conflicts leftovers in >> the filetree repository). >> > > Yes you are right, I expressed myself badly. You don't have to load "the > commits". > But, you still have to create an MCVersionInfo for each version of the > package in the repository. > What you're saying is that you are using the same trick as GitFileTree does, but you have performance issues, which means... we're not talking about exactly the same thing :) (and trust me, my development machine is on the "very" slow end for the Pharo community, so I'm sensitive to performance issues). > > In fact... you can create them, it will not kill you, but I think that > this structure is not so useful, because it is always faster to use > log/revwalk to ask about the relationship between two versions/commits. > Agreed. But you will allways create some sort of MCVersionInfo / MCAncestry to be able to represent the start of this inside your system... Subtypes of MCVersionInfo do work fine there. Just have a nice, correct API call that allow you to compare two versions. (Little trick used in GitFileTree: all ancestry based on a specific commitID is shared among all the versions with it as an ancestor, in memory). Weak version info will take care of cleaning the unneeded stuff anyway. > > Moreover, we do not want to think about packages too much, we prefer to > think in terms of a whole project, so the most interesting concept for us > is the commit and not the version. Therefore, when I build a history > (sometimes I do) I create a graph of commits and not a graph of versions. > As long as you don't track commits for which the package has no version, then that seems perfectly fine. > > Finally, this leads to that, even in the case you want to load a specific > version of a specific pacakge (which is not the normal case for Iceberg), > you would specify a commitish (+ a package name) and not a version name. > I never specify a commitish, I use the GUI or Metacello (and since I'm using baselines, Metacello doesn't uses version numbers except to compare with what is inside the image). GitFileTree only uses commitish to load a version... it just happens to be able to also convert version numbers to a commitish if it is presented with a version number. The attention to version numbering is a thing of people using too much ConfigurationOf, and those people are living in the past. Thierry

1 0