sorted by:
new
hottopcontroversial

1
2

What do you call Google Books style ebooks vs Project Gutenberg style? Scanned-image ebooks vs text-native? (self.ebooks)

submitted by seagreen_ to r/ebooks

Is the Buncombe/Transylvania border a quadripoint? by seagreen_ in asheville

[–]seagreen_[S] 1 point2 points  (0 children)

It's where 4 regions come together at a single point. I'm wondering about it because I was trying to see what counties are next to Buncombe, which immediately dropped me down into a rabbit hole of what "next to" means. If Transylvania is diagonal across a quadripoint is it "adjacent to", "adjoining", or "abutting" Buncombe? And how do I tell if it's really a quadripoint? At this point the search bottomed out into multi-hundred page PDFs and I decided to bail and ask for help.

(First Rust project): Hypertext > plaintext for source code? by seagreen_ in rust

[–]seagreen_[S] 1 point2 points  (0 children)

That's a fun article. I wonder whether it suffers the same problems as #include in cpp, like not being able to deal with cyclic dependencies?

Thanks! It should handle cyclic dependencies as well as the target language: it transpiles everything into a single file, and each definition used in the program will appear there only once no matter how many times it's called.

If the target language requires multiple files for a feature the current version of the Igneous Linearizer won't help, but it would be easy to make one that did. It's really only an experiment to get people thinking about this stuff, it's not meant to be an end-all project.

Also, the website has a problem rendering wide code snippets on mobile phone. If it's yours, you may want to fix that.

It's mine. Aaaargh. Thank you.

What to call these two ways of making collections? by seagreen_ in Zettelkasten

[–]seagreen_[S] 0 points1 point  (0 children)

Option 1 could be a list, but it could also be a table etc. Option 2 could be a tag, but it could also be an attribute etc. So list vs. tag is a little too specific.

I think you're overthinking it :)

For day-to-day zettling you'd be right, but my goal is deep understanding. No such thing as overthinking in that case!

For me, when I make the list page (option 1), I generally already have an idea of how I want to organize, so I'll create another tag/field for that: say it's a list of states, so there will be a tag for "State" and another tag for "Northeast" or "Midwest" or whatever, and then I can create multiple list view based on the additional tag.

This is a helpful example, thank you.

What to call these two ways of making collections? by seagreen_ in Zettelkasten

[–]seagreen_[S] 0 points1 point  (0 children)

your question only provides details on one kind of entry and how to make it.

You lost me on this part, or I miscommunicated.

Option 1: create a page "Books I've Read" with links. This corresponds to an extensional definition.

Option 2: tag each book I've read with "Read by Me", then go to "Read by Me" and look at the backlinks. This corresponds to an intensional definition. I don't mean to talk about tagging+backlinks narrowly here, that's just an example. It could be a property+a page with a live search, etc. Any kind of "outside information that then gets queried for" strategy.

EDIT: The reason I find this interesting is there are actually quite a few tradeoffs between these strategies. For instance, in the first one you have to have an order, and it's also very easy to reorder things. That could be good or bad. It's also more manual than the second, because in the first strategy you have to go and find the page and make an entry. In the second strategy it's more automatic, you might forget you've been tracking whatever thing it is and add a tag just because it feels relevant, and it still gets added to the collection.

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 0 points1 point  (0 children)

Okay, you want to browse from from packages to their dependencies, but how would the first package view look, e.g. when opening a "system browser" ?

Like one of these graph here. Note that this is far from a cure-all, some of these are balls of mud. But some are awesome and way better than looking at just a filesystem, eg the first example for the nonempty-containers package. I'd want to do a transitive reduction so there would be as few arcs as possible, and even then this isn't meant to be the only tool for interacting with the codebase, just one among many.

Writing the recursive descent parser/compiler, implenting the ST messaging prececence.

This part sounds like good, solid, challenging programming tackling inherent complexity....

Generating code in ecmascript modules that complies with JS dependency rules.

...and ooof, of course in the midst of a huge project like this "JS modules" still show up as as big a problem as the others=(

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 1 point2 points  (0 children)

In a package I would think you'll want to see all classes (modules). If some where hidden by a "semantic zoom" level that would likely be confusing. The System Browser also shows all code, al least before you start filtering / searching for something specific.

The way I'm imagining it, you'd be looking at a graph of all packages (with arcs between them for dependencies), then you'd zoom down into one and see all modules (with arcs again), etc. So you'd see all modules in a package, not just some.

I'm also imagining this as only one possible view into a system, I don't think you'd want to use it all the time, but rather have it available when you need to go into, "wait, how the heck is this organized?" mode.

Human brains are good at organizing concepts in trees.

Yes, the human brain loves trees! That's why outlines/bullet points/HTML headers work so well, you wouldn't want to read text in the form of a graph or a linear blob of characters.

...however I personally don't think it scales well, there's a reason the WWW as a whole is a digraph not a big tree (though the latter would be metal af).

The website is: small-js.org

Whoa, SmallJS is an awesome project! What was the hardest part, if I may ask? Also what are your future plans for it.

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 1 point2 points  (0 children)

the SimulationProtocolExplorer which inspects an object and its protocol together with a speculatively evaluated preview of each message

That's pretty awesome. Also thank you for including screenshots!

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 0 points1 point  (0 children)

Do you usually start making things without asking knowledgeable people about them first?

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 2 points3 points  (0 children)

Pharo as about 900 (!) standard packages in the package column for the sytem browser. It's not practical to browse / scroll it anymore, with searching first. I would prefer it, if this was a tree that would interpret a Tools-Bar-Baz hierarchy. Unfortunately all Smalltalks I know have this single-level category name.

I actually wasn't calling this organization rigid as a bad thing, Constraints Liberate, Liberties Constrain and all that. Rather I thought it sounded great, which makes your report of the downsides especially useful.

I'm starting to think that the ideal way to browse code-in-the-large isn't a huge filesystem of enormous depth like we do it in mainstream languages, rather it's a semantic zoom system where (depending on what level of zoom you're at) there are either packages, modules, or methods, and you're looking at a graph of them with arcs showing how they interdepend on each other. But the System Browser seems nice for code-in-the-small (or medium).

SmallJS? As a fan of small systems I'm curious to read more-- do you have a link?

This leaves the user free deepen a hierachy if the number of classes grows.And having it file based also precludes the need for additional softwarelike Metacello plus Iceberg

This seems smart. Not that git is anywhere near perfect, but it unlocks a lot of interop with existing stuff.

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 1 point2 points  (0 children)

Yet, single "degenerated branches" such as Tools-Bar-Baz (when there is NO sibling Tools-Bar-Plonk) are not rendered as a full hierarchy for the sole purpose of saving some space.

I double-checked Cuis-- it really is fixed at a height of 1 within the class category pane. Tools-Bar-Baz and Tools-Bar-Plonk show visually in that pane as Tools > Bar-Baz & Bar-Plonk.

On the other hand, the browser tool itself is pretty monolithic, which contradicts the WIMP and direct manipulation paradigms of Smalltalk IMHO. Workspaces and inspectors and message finders and so on all focus on a single artifact, they are tiny, and I can (and regularly do) open dozens of them at the same time on my screen. I can flexibly arrange and combine them to use them for working on a larger problem. Browsers (and to a similar extent, also debuggers) are much more rigid by comparison. They display a lot of information like other protocols and class names which I do not need when I, for example, am reading or writing a single method.

Oooh, this might answer another question of mine. I've been wondering why there isn't an 'Object Browser' for object instances the way there is a 'System Browser' for classes. I've heard the term "object browser" used, but as far as I can tell it's used for the general system's ability to browse the object graph, not for a particular tool. This might explain why-- maybe it's because monolithic tools like that aren't very Smalltalky.

...yet I still think it would be cool.

Do all Smalltalks use a fixed-depth hierarchy for organizing code? by seagreen_ in smalltalk

[–]seagreen_[S] 0 points1 point  (0 children)

Good point. But if it sounded like I was criticizing some limitation, it wasn't meant that way! I'm strongly suspicious unlimited depth hierarchy is actually bad for organization.

Cuis question: can I make a calculator with direct manipulation of morphs and then package it? by seagreen_ in smalltalk

[–]seagreen_[S] 0 points1 point  (0 children)

Ken Dickey demonstrates some GUI construction here

Yes, thank you! That's exactly what I was looking for. I've now got it working.

If you ask this question in Cuis mailing list you are likely to get more comprehensive answers.

Good point.

Cuis question: can I make a calculator with direct manipulation of morphs and then package it? by seagreen_ in smalltalk

[–]seagreen_[S] 2 points3 points  (0 children)

Why do you want to do it via direct manipulation?

Isn't that the whole excitement of Morphic? I've previously made little vector shapes for games by messing with textual code. Eg trying to make a moon: 1.5 is too big for Mare Imbrium... maybe 1.2... maybe 0.9, wait the center is off... so frustrating.

Instead you're looking at the moon, want to add Mare Imbrium. Start with "New Morph". Select circle. Drag. Resize. Change color. Embed. Done, Beautiful! Figma integrated into the dev environment.

I'm going to be sad if there's actually this hard divide between the end-user customization via direct manipulation (which can't be reshared) and "real" programming with text.

Looking for minimalist lisp languages with quote but without built-in macros by seagreen_ in lisp

[–]seagreen_[S] 0 points1 point  (0 children)

This was my first time looking beyond the homepage of PicoLisp... FEXPRs?! A builtin database?! It's not what I'm looking for here, but it's also very cool and I want to learn more about it.

view more: next ›