Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pharo 8.0

pharo.org

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Pharo 8.0

#91

Post by masukomi »

lucas_membrane wrote: post #38
fmakunbound wrote: post #19

Earlier quoted context omitted.

I also thoroughly enjoy Seaside. There's also https://iliadproject.github.io/ for another approach.

Iliad says Latest commit 0be1977 on Jul 18, 2017. Seaside says last commit 24 August 2019. Any actively maintained web framework that will work with Pharo 8?

keep in mind that smalltalk is freaking ancient and like most useful but freaking ancient things in unix, most of the stuff "just works" and doesn't need constant poking.

Also, Smalltalk offers a much more transparent development environment. So, you're not writing code that goes into a black box and produces results. You can see what's going on in the box and make sure its doing it correctly.

also, the Squeak by example book (i think Pharo by example is a fork of this) very quickly starts showing people how to write tests. So the mentality isn't "oh, yeah, i guess i could add tests" it's "oh hey, tests are part of making smalltalk code" so you've got that going for it too.

combine those things with the smaller community, and thus a much more narrowly defined set of "needs" for a web framework and yeah, it doesn't get poked constantly.

but that's ok.

Re: Pharo 8.0

#92

Post by masukomi »

hliyan wrote: post #64

Five clicks through from the home page and I still can't seem to find a "Getting started" / "Hello World" example.

Books: https://books.pharo.org/

Pharo by Example should be a good starting point.

Developing in Smalltalk is unlike EVERYTHING else. As noted by seandenigris standard assumptions about things like "hello world" don't apply.

Re: Pharo 8.0

#93

Post by atemerev »

badsectoracula wrote: post #72
atemerev wrote: post #14

Earlier quoted context omitted.

Every Macbook after around 2015 is HiDPI. Windows Surface laptops, too. Hardly "practically do not exist in the wild". I love Smalltalk, but I am not qualified to rewrite the entire Pharo rendering layer, unfortunately. Also, statscounter doesn't account for high resolution displays at all, grouping them all as "other". And these are around 20%.

These are still very few compared to every other desktop available out there. I said they are rare, not that they do not exist. If statscounter isn't up to your liking, then check: https://www.screenresolution.org/ (typical desktop HiDPI resolutions like 3840x2160 are at ~0.1%) https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... (gamers tend to have higher specs in their computers and 4K is a big trend in…

The first link counts 4k displays with 2x scaling as 1920x1080. It doesn’t seem to differentiate for hidpi monitors. People who use 4k displays without UI scaling are rare indeed. Perhaps macs are “rare” (though 7% is hardly rare). HiDPI desktops are still rare indeed. But HiDPI laptops are pretty common these days.

When I first saw a hidpi display (on iPhone 4), this was a game changer for me. Since then, I don’t understand how it is even possible to settle for something with visible pixels. iPhone 4 was releases 10 years ago.

Re: Pharo 8.0

#94

Post by zamadatix »

badsectoracula wrote: post #82
zamadatix wrote: post #73

Earlier quoted context omitted.

"Desktop" includes laptop at statcounter. 1080p is supposed to be 23". And again if it's simply the resolution the browser reports it is post scale so a 2560x1440 laptop at 150% would show as 1920x1080 anyways. It's web stats, they only care about the size of the viewport.

Yes, i'm also talking about laptops here, not just desktops. If you can go by with 150% this isn't HiDPI (and on most laptops 150% for 1080p is too big anyway, at least on Windows, you want something around 125%). HiDPI is something that you need at least 200%, like Apple's 2560x1600 at 13" where anything less is unusable. Using 100% scaling on a laptop at 1080p is perfectly fine (this is my laptop configuration and…

Anything above 100% is considered high DPI on Windows, including 125%. I.e. if the display DPI is not 100% and the app isn't DPI aware you will end up with a blurry mess since the OS will stretch the app for you via bitmap scaling by a factor of DPI / 100%. Apple is the only one that does integer factor only DPI for their hardware (100%, 200%, 300%...) and their entire current lineup is >100% now.

Re: Pharo 8.0

#95

Post by singlow »

drivers99 wrote: post #26
singlow wrote: post #18

Earlier quoted context omitted.

It is optional to let CloudFlare cache the content. I believe you can control it from the CloudFlare control panel as well as affect it from your HTTP headers. So I bet they have the feature enabled on the panel but their HTTP headers tell CloudFlare not to cache the page, maybe accidentally.

It is caching the static assets (js, css, png, etc) based on default extensions[1]. The page itself is dynamic, likely for the comment feature at the bottom of the page. If they wanted to cache it, they could probably add some caching headers (have to change the responses on the origin) or a Page Rule in cloudflare (and not have to change anything on the server). But that won't be a good idea if people can login to t…

Cookie-based cache by-pass is a premium paid-only feature last time I used CloudFlare.

Re: Pharo 8.0

#96

Post by seandenigris »

alxndr wrote: post #86
seandenigris wrote: post #79

Earlier quoted context omitted.

Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity…

> I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity. Wow, any chance you've written about the upgrade process?

I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...

Re: Pharo 8.0

#97

Post by masukomi »

AtlasBarfed wrote: post #66

Great. Super. Has it been ported to a "real" VM yet? I'm going off of Wikipedia and the 16-bit windows error below. I can see that the "radical: always-debug, always-on might need a real VM, but it's apparent there isn't enough base for this to produce a true VM. Is it really impossible to port to the JVM, the javascript VMs, or something similar? Otherwise I fear this is doomed to toy status.

two things. First though, please google before getting all dismissive.

1) YES smalltalk _has_ been ported to the JVM https://www.redline.st/ AND you can also run it in the GraalVM https://www.graalvm.org/

2) I'm pretty sure the initial JVM was a clone / extension of a Smalltalk VM. Having trouble googling the details, but while you may be having trouble getting it to work on your particular Windows install you might want to consider that you're possibly ignorant of the fact that the Smalltalk VM is not only one of the best available but battle tested over decades.

I would guess that what you're seeing is a particular windows issue that has nothing to do with the VM itself.

Re: Pharo 8.0

#98

Post by AtlasBarfed »

masukomi wrote: post #97
AtlasBarfed wrote: post #66

Great. Super. Has it been ported to a "real" VM yet? I'm going off of Wikipedia and the 16-bit windows error below. I can see that the "radical: always-debug, always-on might need a real VM, but it's apparent there isn't enough base for this to produce a true VM. Is it really impossible to port to the JVM, the javascript VMs, or something similar? Otherwise I fear this is doomed to toy status.

two things. First though, please google before getting all dismissive. 1) YES smalltalk _has_ been ported to the JVM https://www.redline.st/ AND you can also run it in the GraalVM https://www.graalvm.org/ 2) I'm pretty sure the initial JVM was a clone / extension of a Smalltalk VM. Having trouble googling the details, but while you may be having trouble getting it to work on your particular Windows install you might…

I did, yes I know that Smalltalk needed a VM, Pharo == smalltalk, and the like.

Wikipedia for Pharo says they have a VM with JIT, etc. I have never heard a peep about the Smalltalk VM in any circumstance as a performant target for any language. Ever.

If it's battle tested and great, why isn't it used for anything else than Smalltalk ports? Is there a python, ruby, javascript, java, etc port to the smalltalk VM?

If it sounds like I'm being dismissive, that's not the point. The point is the Smalltalk ecosystem, like Lisp derivatives, likes to have its own top-to-bottom stack completely isolated from "real" execution platforms.

For Lisp it's so bad that Clojure is rejected by some Lisp purists because it can JVM / JS compile.

IMO, for example, Ruby made a strategic error writing their own VM rather than just embracing the JVM as the main VM, although when Ruby was writing their VM invokedynamic hadn't been added to the JVM. Well, and they should have added some optional typing.

Post reply on HN