Sent from my iPad
> On Jan 3, 2016, at 03:49, Esteban Lorenzano <[email protected]> wrote: > > >> On 03 Jan 2016, at 10:11, John Pfersich <[email protected]> wrote: >> >> >> >> Sent from my iPad >> >>>> On Jan 2, 2016, at 23:57, Saša Janiška <[email protected]> wrote: >>>> >>>> On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote: >>>> >>>> there is an an SQlite wrapper for pharo >>> >>> I know about it. >>> >>> However it would be nice to have some categorized catalog of the >>> packages available for Pharo? >> >> +1 >> I find that I just browse the Configuration Browser to see what's out there >> and then google the name to see if I can find any documentation. > > you have it: > > http://catalog.pharo.org > > configuration browser was not good enough so we replaced it in Pharo 5 > (packages can be used in older versions, and they are listed in the catalog > web page). > but again… no tool can survive if people does not contribute. > > Esteban > You should add a link to catalog.pharo.org on the documentation page on Pharo.org. I find it is a very useful tool. >> >> And it would be nice to have a wiki like Squeak's. >> >>>> the screenshot you shared as Tudor said can be accomplished via >>>> Roassal and Morphic. >>> >>> Now, I'm really a bit puzzled about Roassal' capabilities. :-) >>> >>>> Personally I find the whole performance question kinda irrelevant >>>> because if you really want to squeeze the most performance code those >>>> parts in C and call them from Pharo via its FFI. Not even Julia will >>>> able to outperform that since itself relies on C code for performance >>>> and its quite restrictive how you use its dynamic types to achieve >>>> high performance. >>> >>> Well, the point is that e.g. I know people who tried to do similar apps >>> in Python and it was too slow, they abandoned it and went to C++. >>> >>> That's the reason why I was primarily exploring statically-compiled >>> languages. Julia *might* be interesting since it is higher-level >>> language with fantastic, close to C performance when one helps compiler >>> by annotating data types. >>> >>> In short, I want to avoid fiddling with low-level languages, otherwise >>> it would be simple to just use C/GTK or C++/Qt. (Java could probably >>> also do the job, but I simply do not like it.) >>> >>> For the most critical part of the application, I anyway plan to use 3rd >>> party C lib which does calculate planetary ephemeris, but for the custom >>> libs using it, I want to use higher-level and type-safer language. >>> >>>> In any case there are always 3 rules, profile, profile and profile. >>>> When it comes to performance assume nothing. In the vast majority of >>>> cases Pharo JIT VM should be more than enough. >>> >>> Let me see... >>> >>>> And if all you want to do is a business app I dont even know why you >>>> worry about performance. Business apps they are very low demand on >>>> performance. >>> >>> When I say 'business' app, it is most in the sense of typical 'desktop >>> outlook', while the app itself is falling more into 'science' app, but >>> it depends how one sees astronomy/astrology. :-) >>> >>>> Pharo libraries dont get irrelevant because the language is so simple >>>> it barely changes and the changes usually dont brake compatibility. >>> >>> Pharo's simplicity of the language is huge 'pro'. ;) >>> >>>> Pharo can do REPL via the playground, the whole deal is that is a lot >>>> more than that. >>> >>> Right, it's just that Julia provides more 'traditional' dev work-flow, >>> while with Pharo one has to unwrap one's head a bit. :-) >>> >>>> GUI wise you can do some pretty awesome stuff with morphic. >>> >>> That I still have to learn... >>> >>> >>> Sincerely, >>> Gour >>> >>> -- >>> A person is said to be elevated in yoga when, having renounced >>> all material desires, he neither acts for sense gratification >>> nor engages in fruitive activities. >
