> On 03 Jan 2016, at 10:11, John Pfersich <jpfers...@gmail.com> wrote: > > > > Sent from my iPad > >> On Jan 2, 2016, at 23:57, Saša Janiška <g...@atmarama.com> 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 <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 > > 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. >> >> >> >> >> >
