2024/10/13

Newest at the top

2024-10-13 21:19:56 +0200ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en
2024-10-13 21:19:17 +0200merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-10-13 21:14:48 +0200machinedgod(~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 252 seconds)
2024-10-13 21:14:09 +0200rvalue(~rvalue@user/rvalue) rvalue
2024-10-13 21:13:36 +0200rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-10-13 21:08:33 +0200merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-10-13 21:08:03 +0200 <monochrom> Is it like you have your own shell script and you name it "gcc" to intercept usages of gcc and change some arguments and you would really like to avoid parsing a response file? :)
2024-10-13 21:06:42 +0200 <monochrom> _d0t: Now I'm curious. (Just curious.) What needs to be hacked around? :)
2024-10-13 21:06:18 +0200acidjnk_new(~acidjnk@p200300d6e72cfb115c8ca2f660dd1d29.dip0.t-ipconnect.de)
2024-10-13 21:05:56 +0200Pixi(~Pixi@user/pixi) Pixi
2024-10-13 21:03:56 +0200 <Square> dminuoso, "Q: how many types". Unclear. But possibly 50ish.
2024-10-13 21:03:32 +0200merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-10-13 21:03:00 +0200 <Square> The generation of schema + java types would be part of the build, so any changes in types would lead to compile errors - if not adapted in java.
2024-10-13 21:02:29 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2024-10-13 21:01:53 +0200 <Square> parts of a java application*
2024-10-13 21:01:38 +0200 <Square> My use case is migrating parts of an application to Haskell and having an RPC mechanism calling Haskell from Java. Ideally i would like to replicate a bunch of haskell types in java (limiting myself to constructs it supports).
2024-10-13 21:00:42 +0200caconym(~caconym@user/caconym) caconym
2024-10-13 21:00:17 +0200 <dminuoso> Also think about code generators (the other way around), they tend to be esaier.
2024-10-13 21:00:06 +0200caconym(~caconym@user/caconym) (Quit: bye)
2024-10-13 21:00:02 +0200 <dminuoso> How many data types are we talking about here?
2024-10-13 20:59:31 +0200 <dminuoso> It increases coupling, introduces bugs quickly when you make modifications, and delays separating the network representation properly, possibly with versioning even.
2024-10-13 20:58:25 +0200 <Square> s/in don't/in I don't/
2024-10-13 20:58:07 +0200 <Square> dminuoso, I know an argument, it could make my work so much easier in don't having to replicating the model by hand in another language.
2024-10-13 20:57:53 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 245 seconds)
2024-10-13 20:57:13 +0200 <_d0t> Otherwise I'll just have to hack around this.
2024-10-13 20:57:09 +0200 <dminuoso> Certainly promoted by the ease of `Generic` and` ToJSON/FromJSON.
2024-10-13 20:57:07 +0200 <_d0t> geekosaur: i mean, i was just wondering if there was a way already.
2024-10-13 20:56:58 +0200 <dminuoso> Tying your wire format to your semantic data model is a classic mistake.
2024-10-13 20:56:43 +0200 <dminuoso> In fact, you should probably have an intermediate data type representing the format instead.
2024-10-13 20:56:36 +0200 <geekosaur> you''d have to ask in #ghc but I strongly suspect they're not interested in having to maintain multiple ways to invoke gcc
2024-10-13 20:56:29 +0200 <dminuoso> Square: As they shouldn't.
2024-10-13 20:56:13 +0200 <Square> dminuoso, Maybe I should. I just feel most of these formats are crude and doesn't lend themselves in replicating a data model in another language.
2024-10-13 20:56:09 +0200 <_d0t> yeah, i meant response file https://gcc.gnu.org/wiki/Response_Files
2024-10-13 20:55:47 +0200 <geekosaur> the problem is that Windows command lines are way too short
2024-10-13 20:55:41 +0200 <_d0t> geekosaur: ok but what if I don't care about windows?
2024-10-13 20:55:36 +0200 <geekosaur> I think they mean response file
2024-10-13 20:55:28 +0200 <geekosaur> _d0t, generally not because of Windows compatibility
2024-10-13 20:55:28 +0200 <monochrom> resource file? Is that Windows?
2024-10-13 20:54:39 +0200Pixi(~Pixi@user/pixi) (Quit: Leaving)
2024-10-13 20:54:36 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2024-10-13 20:54:34 +0200 <dminuoso> Dont think of a 1:1 mapping of haskell, and just think about how you encode the idea in a format, and then keep a schema for that.
2024-10-13 20:54:29 +0200CrunchyFlakes(~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Quit: ZNC 1.8.2 - https://znc.in)
2024-10-13 20:54:19 +0200 <_d0t> ohai! Is there a way to force GHC to pass command-line args to GCC directly instead of through a resource file (ghc_X.rsp)?
2024-10-13 20:53:40 +0200 <Square> dminuoso, I feel it does have something todo with schema generation though.
2024-10-13 20:53:38 +0200 <dminuoso> Depending on the surrounding code, you could also work with a GADT
2024-10-13 20:52:29 +0200 <dminuoso> What you are asking about has nothing to do with the serialization format
2024-10-13 20:52:10 +0200 <dminuoso> Add a (Typeable a, Typeable b) constraint to your serialization function, and work with that?
2024-10-13 20:51:57 +0200merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-10-13 20:51:24 +0200 <Square> data MyType a b = MyType a b
2024-10-13 20:50:44 +0200 <dminuoso> What do you mean by type parameters?