Newest at the top
| 2025-01-16 01:50:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:50:09 +0100 | JuanDaugherty | ColinRobinson |
| 2025-01-16 01:50:04 +0100 | <Guest71> | JuanDaugherty: sorry, I'm not sure what you meant by that (re: namespaces being just namespaces) |
| 2025-01-16 01:49:11 +0100 | <Guest71> | It's a numeric library |
| 2025-01-16 01:49:06 +0100 | <Guest71> | It basically combines a bunch of numeric interfaces and add some other stuff on top |
| 2025-01-16 01:48:40 +0100 | <Guest71> | I'm currently in the process of trying to publish it, hence this conversation :) |
| 2025-01-16 01:48:15 +0100 | <Guest71> | Oh, sorry, it isn't public as of right now. |
| 2025-01-16 01:47:44 +0100 | <JuanDaugherty> | can a namespace just be a namespace? names r powerful, their rectification is a whole deal |
| 2025-01-16 01:47:38 +0100 | <jackdk> | Ideally a link to a high-level API page. So far I have found a page on cloud-based aged care software and a PDF report from a consultancy about Smart Meters for the Australian Energy Market Commission. Please, help us help you. |
| 2025-01-16 01:47:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8310:6e2:3d63:5127) (Ping timeout: 248 seconds) |
| 2025-01-16 01:46:13 +0100 | <Guest71> | Though I imagine you were hoping for something descriptive |
| 2025-01-16 01:45:51 +0100 | <Guest71> | jackdk: it's called Nera |
| 2025-01-16 01:45:08 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 01:44:49 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-16 01:43:45 +0100 | <jackdk> | At least its name, I mean. |
| 2025-01-16 01:43:37 +0100 | <jackdk> | I think knowing the specific interface would be extremely helpful, if you can provide it. |
| 2025-01-16 01:43:21 +0100 | <JuanDaugherty> | "module" is more of a construct and often enough contentious, eg. in prolog |
| 2025-01-16 01:42:59 +0100 | <Guest71> | The project originally had a form of Foo.Iface, Foo.Bar.Baz1, Foo.Bar.Baz2, Foo.Bar.Baz3... all the BazN modules implement the Foo.Iface |
| 2025-01-16 01:41:57 +0100 | <Guest71> | I can tell more about the project, it's not a secret. I just don't want to overwhelm you with noise. |
| 2025-01-16 01:41:41 +0100 | <JuanDaugherty> | cause in that time computers were called ibm machines so their usages became industry norms, even tho there was actually much greater arch diversity |
| 2025-01-16 01:41:15 +0100 | <geekosaur> | there is no real concept of related-ness; a different package could also use the Foo.Bar "namespace" |
| 2025-01-16 01:40:58 +0100 | <jackdk> | Without knowing what the mysterious API is, it sounds like the bindings are more loosely coupled than Amazonka's. This makes me lean toward either option 1c (monorepo with split packages) or 3 (split repos with individual release infrastructure) |
| 2025-01-16 01:40:57 +0100 | <geekosaur> | modules |
| 2025-01-16 01:40:51 +0100 | <Guest71> | The modules called Foo.Bar.* |
| 2025-01-16 01:40:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-16 01:40:44 +0100 | <Guest71> | What do I call everythin under Foo/Bar? |
| 2025-01-16 01:40:40 +0100 | <haskellbridge> | <sm> a project can consist of one or more repos which may store one or more packages |
| 2025-01-16 01:40:36 +0100 | <Guest71> | As in I have lib/Foo/Bar/Baz.hs |
| 2025-01-16 01:40:33 +0100 | <geekosaur> | if you mean module namespaces, they're pretty fake |
| 2025-01-16 01:40:19 +0100 | <geekosaur> | which kind of namespace? |
| 2025-01-16 01:40:16 +0100 | <JuanDaugherty> | yes them |
| 2025-01-16 01:40:05 +0100 | <Guest71> | Okay, point taken. What's the best way to call everything under a namespace? |
| 2025-01-16 01:40:04 +0100 | sprotte24 | (~sprotte24@p200300d16f35c200f4f310a9fb58ced0.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-01-16 01:40:03 +0100 | <geekosaur> | (for which we have IBM to blame, IIRC) |
| 2025-01-16 01:39:56 +0100 | <haskellbridge> | <sm> +1 to jackdk. "package" is the right term for units of hackage/cabal/stack-stuff |
| 2025-01-16 01:39:37 +0100 | <JuanDaugherty> | as opposed to "object module" |
| 2025-01-16 01:39:10 +0100 | <JuanDaugherty> | 'source module" is an ancient idiom for a single file of code text |
| 2025-01-16 01:38:56 +0100 | <Guest71> | sm: I'm expecting not, except for users that happen to have different use-cases that could be better served by different implementations |
| 2025-01-16 01:38:01 +0100 | <haskellbridge> | <sm> will people often want to install all the packages together ? It sounds like not |
| 2025-01-16 01:37:43 +0100 | <jackdk> | That Haskell calls a source file a "module" means I find it confusing to call a unit of project organisation a "submodule", especially when that word had meaning to `git`. For clarity: a cabal "package" has multiple "components" (library, named sublibrary, executable, test suite, etc). One or more "packages" on the filesystem can be collected into a "project", where `cabal.project` lets you apply settings across them. |
| 2025-01-16 01:36:40 +0100 | <Guest71> | sm: issue tracker per package, yes. Docs are basically pure Haddock, so they are split already. I would not release in lockstep. |
| 2025-01-16 01:36:18 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-16 01:35:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 01:34:24 +0100 | <haskellbridge> | <sm> I think we don't know enough to have (more of :) an opinion |
| 2025-01-16 01:33:32 +0100 | <Guest71> | As for the boundary enforcement, it is true that you may enforce it with cabal. I suppose in my mind that is a sort of "softer" enforcement than splitting repos (boundary enforcement is regulated by a file inside the project repo), so I just reached for the most generic solution. Maybe this was a bad call? |
| 2025-01-16 01:33:31 +0100 | <Guest71> | I was going to say that I wasn't meaning to say git submodules, but Haskell submodules (let's call them subprojects). What I was trying to say is that keeping a monorepo means that a subproject's history is merged together with everything else, which means more work around handing history. |
| 2025-01-16 01:33:25 +0100 | <haskellbridge> | <sm> issue tracker per package ? |
| 2025-01-16 01:32:44 +0100 | <haskellbridge> | <sm> will docs/changelogs be easy to segment by package ? Will you always release all packages in lockstep, or will you allow say a bugfix release to an individual package, complicating release scripts ? etc. |
| 2025-01-16 01:30:34 +0100 | <haskellbridge> | <magic_rb> Ive heard that overly polymorphic code doesnt specialize well, but then id ask why? Because couldnt GHC track what different instantiations of each toplevel binding occur and then based on some metric (plain count, expected machine code size) specialize automatically? I assume something like this happens already, but question is why not well enough where "overly polymorphic" ceases to be a problem |
| 2025-01-16 01:30:02 +0100 | <jackdk> | I just had the strangest case of deja vu |