2023-11-17 04:03:15 <veltas      > KipIngram: Could this be of any interest to you? https://www.ultorg.com/
2023-11-17 04:04:01 <veltas      > I know you do a lot of messing with databases, seems like an interesting tool. I tried a Beta version of it ages ago to try and rationalise a Jira CSV dump and the dev was quite helpful fixing bugs in it
2023-11-17 05:56:51 <KipIngram   > veltas:  It could be; I'll take a look.  I mostly push data into and out of my database with Python and bash, but you never know.
2023-11-17 06:10:36 <KipIngram   > Hmmm.  Ok, something to try today.
2023-11-17 06:11:31 <KipIngram   > One little database tool I've written extracts all values of a particular measured quantity for a given test job from the database.
2023-11-17 06:12:12 <KipIngram   > That is a two level query - first I have to find all of the data "bundle" ids that hold that type of quantity.
2023-11-17 06:12:33 <KipIngram   > That's one bundle per job "step" and I order them chronologically.
2023-11-17 06:12:55 <KipIngram   > Then I loop through all of those bundle ids and get the actual data values for that number, again ordered chronologically.
2023-11-17 06:13:23 <KipIngram   > I currently do that with a query followed by a bash for loop over a second query, and i use >> to append each set of data to the growing list.
2023-11-17 06:14:02 <KipIngram   > This works, but ever since that issue the other data where the guy had to expand my database storage step it runs considerably more slowly.  Takes maybe 40 seconds on a typical job instead of perhaps five seconds previously.
2023-11-17 06:14:27 <KipIngram   > But there is info here on parallelizing bash for:
2023-11-17 06:14:29 <KipIngram   > https://unix.stackexchange.com/questions/103920/parallelize-a-bash-for-loop
2023-11-17 06:14:41 <KipIngram   > I just ran one of the examples given there and that works.
2023-11-17 06:15:14 <KipIngram   > So, I wonder if perhaps I can batch parallelize the for loop MySQL query, and save the results into individual files.  And THEN loop over those files appending them.
2023-11-17 06:15:22 <KipIngram   > Shouldn't be hard to check and see.
2023-11-17 06:15:36 <KipIngram   > I've actually never exploited the ability to parallelize query to the db at all.
2023-11-17 06:17:28 <KipIngram   > Where it would really pay off is in harvesting my job results directory; there are many many individual files of fio data to process, and in theory those processing steps are totally independent of one another.
2023-11-17 06:17:37 <veltas      > Wait sorry I'm not a database expert but it does seem like a big power of relational databases is to give the whole query, even if it is 'two levels', so it can optimise / do in parallel itself
2023-11-17 06:17:43 <KipIngram   > But that's Pythoon and you have to jump a few hoops to parallelize Python.
2023-11-17 06:17:54 <veltas      > It sounds a bit broken to do it in bash/python
2023-11-17 06:17:59 <KipIngram   > Yes, you can do that, but it slowed down the other day.
2023-11-17 06:18:12 <KipIngram   > Such tools are not always "efficient" at nesting queries.
2023-11-17 06:18:16 <KipIngram   > There are multiple ways of doing it.
2023-11-17 06:18:20 <KipIngram   > One is like this:
2023-11-17 06:18:52 <veltas      > I think the database experts in here would be interested in an outline of the actual queries you're using
2023-11-17 06:18:56 <veltas      > And might have something to say about it
2023-11-17 06:18:57 <KipIngram   > select ind, dep from data where bundle in (select id from bundles where <blah> <blah>) order by ind;
2023-11-17 06:19:27 <KipIngram   > Or you can do it by first creating a temporary table containing the bundle ids and then say (select id from temp_table) in that inner query.
2023-11-17 06:19:38 <KipIngram   > The first way, without the temporary table, has ALWAYS been extremely slow.
2023-11-17 06:20:00 <KipIngram   > But before last week the temp table way took about five seconds, and now it is prohibitively slow as well.
2023-11-17 06:20:02 <veltas      > Well now we wait and hope an SQL adult can help
2023-11-17 06:20:23 <KipIngram   > I think the stuff the IT guy did to expand my storage space killed the effectiveness of one of my database indices somehow.
2023-11-17 06:20:33 <KipIngram   > Indices do have to be maintained over time.
2023-11-17 06:20:52 <KipIngram   > I haven't really needed to, because I never delete anything from this db - I just "add to it."
2023-11-17 06:20:56 <KipIngram   > So the files just "grow."
2023-11-17 06:21:12 <KipIngram   > But he copied big files around while doing what he was doing, and somehow it broke efficiency.
2023-11-17 06:21:18 <KipIngram   > Yes.
2023-11-17 06:21:34 <KipIngram   > I'm poking around to find one of those.
2023-11-17 06:21:45 <KipIngram   > Because I am NOT a database adult.
2023-11-17 06:21:52 <KipIngram   > Nice way of putting it, by the way.
2023-11-17 06:22:53 <KipIngram   > I have a feeling, though, that this might parallelize nicely - it might approach linear speedup.  Approach - not get there.
2023-11-17 06:22:56 <veltas      > I'll admit SQL is total magic to me, I don't understand it at all
2023-11-17 06:23:13 <KipIngram   > Well, you would quickly if you looked into it.
2023-11-17 06:23:14 <veltas      > I have a gut feeling there's one query that will do this, maybe in just one level
2023-11-17 06:23:19 <KipIngram   > It's fairly straightforward.
2023-11-17 06:23:26 <veltas      > I've looked into it, it doesn't fit with my brain at all
2023-11-17 06:23:40 <veltas      > I'm too linear with my programming, can't cope with declarative stuff
2023-11-17 06:23:42 <KipIngram   > There are some fancy things called joins, but I don't know how to work those.
2023-11-17 06:24:42 <KipIngram   > All you're really doing with basic queries is choosing a table, finding all rows of that table that match a criterion, and returning those rows (or row items - you don't have to take the whole row) in some chosen sequence.
2023-11-17 06:25:09 <veltas      > Joins are sort of the bread and butter of relational database work if I understand
2023-11-17 06:25:26 <KipIngram   > Yes, I think so.  My schema is so veyr simple, though.
2023-11-17 06:25:59 <veltas      > Or certainly the bread and butter of normalised relational databases
2023-11-17 06:26:06 <veltas      > Is your database nicely normalised?
2023-11-17 06:26:09 <KipIngram   > Nothing I'm doing here is very sophisticated.  In fact, I realized a day or two ago I really could have done it all with files and not  used a db at all.
2023-11-17 06:26:27 <KipIngram   > Fairly  normalized.  I don't have data overtly dupicated anywhere.
2023-11-17 06:26:57 <KipIngram   > I do put average, min, and max values of each bundle's data in that bundle row, which is "kind of" redundant.
2023-11-17 06:27:15 <KipIngram   > Makes it so I don't have to fetch all the data and average it every time I need that average.
2023-11-17 06:27:31 <KipIngram   > I pre-computed them.  i don't know if that's considered a normalization boo boo or not.
2023-11-17 06:27:50 <KipIngram   > But yes - basically the db is just a three level tree.
2023-11-17 06:28:07 <KipIngram   > Jobs, bundles associated with jobs, data points associated with bundles.
2023-11-17 06:30:10 <KipIngram   > Each bundle specifies a job number, a test step name, and a "measured quantity."  That triple is unique database wide.
2023-11-17 06:30:28 <KipIngram   > Then each data row specifies a bundle id and an independent data value, and that pair is unique.
2023-11-17 06:35:17 <KipIngram   > Anyway, the basic thing this will depend on is whether I can concatenate files faster than I can get individual data bundles from the db.
2023-11-17 06:35:24 <KipIngram   > I'm guessing that's probably "yes."
2023-11-17 06:36:28 <KipIngram   > I do want to batch it - there might be thousands of bundles involved and I don't really want to throw off thousands of child processes.
2023-11-17 06:36:50 <KipIngram   > It's not Erlang.  :-)
2023-11-17 06:37:18 <KipIngram   > I'll probably try batches of 10 or 20 and see if that gets me anything interesting.
2023-11-17 06:38:00 <KipIngram   > I should make a project out of parallelizing the harvest tool; that would pay off extremely well, I think.
2023-11-17 06:39:09 <KipIngram   > And I should also experiment with "not avoiding' harvest multiple jobs in parallel.  I just haven't tried it - I harvest them one at a time when I have several finished at once.
2023-11-17 06:39:33 <KipIngram   > Really though, even harvesting my longest test only takes a couple of minutes.
2023-11-17 06:40:10 <KipIngram   > But there's a perfect way to parallelize it.  The results come out of the fio tool as a set of directories each with a set of log files.
2023-11-17 06:40:18 <KipIngram   > I loop over directories and inner loop over files.
2023-11-17 06:40:36 <KipIngram   > I could parallelize both levels.
2023-11-17 06:40:49 <KipIngram   > Like I said, there is no dependency among those files at all.
2023-11-17 06:41:40 <KipIngram   > I do think, however, that one reason the database has stayed as fast as it has is because I've kept it very tidy.  Each bundle's data is in a contiguous block in the data table.
2023-11-17 06:41:57 <KipIngram   > If I parallel harvest they'd probably get interspersed with one another.
2023-11-17 06:57:28 <KipIngram   > This is the business part of the little test i just ran:
2023-11-17 06:57:32 <KipIngram   >   for thing in $(seq 40) ; do
2023-11-17 06:57:34 <KipIngram   >     ((i=i%N)); ((i++==0)) && wait
2023-11-17 06:57:36 <KipIngram   >     task "$thing" &
2023-11-17 06:57:38 <KipIngram   >   done
2023-11-17 06:57:40 <KipIngram   >   wait
2023-11-17 06:57:45 <KipIngram   > I'm not really sure how that's all working, but it seems to.
2023-11-17 06:58:07 <KipIngram   > I don't know bash mechanics quite well enough to know what the two lines in the for loop are actually DOING.
2023-11-17 06:58:39 <KipIngram   > Especially the ((i++==0)) bit.
2023-11-17 07:00:36 <KipIngram   > In particular, I'm not sure whether it's running batches of N items or N batches.
2023-11-17 07:01:38 <KipIngram   > My guess is batches of N.
2023-11-17 07:56:07 <veltas      > Regards to pre-computing, I would guess it's alright if it doesn't make the table much larger
2023-11-17 07:56:18 <veltas      > If it does then you're making a false economy
2023-11-17 07:56:32 <veltas      > Because disk read is slow anyway etc
2023-11-17 08:12:47 <KipIngram   > Yes.  There's a fair bit of information in the bundle rows.  That made including the stats a fairly modest percentage space increase.
2023-11-17 08:12:59 <KipIngram   > The bundle table is much smaller than the data table anyway.
2023-11-17 08:13:40 <KipIngram   > Rows of the data table only have three items (bundle, independent, dependent), but there are a lot of them.
2023-11-17 08:14:04 <KipIngram   > That data is either some quantity vs. unix epoch time or else it's a set of histogram bin counts.
2023-11-17 08:22:33 <KipIngram   > I realized a few days ago that in the foreseeable future (maybe 2-3 years) I will run out of bundle ids.  I made the bundle id columns INT(10) and I have used up about 60% of that capacity at this point.
2023-11-17 08:22:51 <KipIngram   > When i migrate this thing to the new server I need to expand that column to INT(11).
2023-11-17 08:23:36 <KipIngram   > I probably will wait until then to try to square the index away again too.  It's working "well enough" currently.
2023-11-17 08:23:57 <KipIngram   > I have no idea how  hard that migratin is going to be - it won't shock me if it takes days and days.
2023-11-17 08:24:28 <KipIngram   > If I migrate all of it - I might just take the last N years for N smaller than the total.
2023-11-17 08:25:45 <KipIngram   > I may just ask the IT guy if we can shut down the existing VM but leave it "hanging around" in case some bizarre situation pops up that makes me need my oldest data.
2023-11-17 08:26:01 <KipIngram   > Then I'd just move some reasonable fraction of it to the new system.
2023-11-17 08:33:59 <KipIngram   > oh, hmmm.  What I just said is entirely wrong.  I don't seem to be in trouble for bundle space at all.  I saw something the other day that made me think I was, but I now can't imagine what it is.
2023-11-17 08:34:21 <KipIngram   > I'm only up to bundle id 11092974.
2023-11-17 08:34:38 <KipIngram   > Hardly dented INT(10).
2023-11-17 08:51:03 <veltas      > This looks quite good https://github.com/jibsen/tinf
2023-11-17 08:51:14 <veltas      > Might use it / fork it if I need inflate for something
2023-11-17 08:51:29 <veltas      > Looks to be an inflate algorithm in not very much C
2023-11-17 08:51:47 <veltas      > (inflate i.e. the decompression algorithm for zlib / zip / compress HTTP etc)
2023-11-17 08:52:18 <veltas      > It does compression too but I wasn't interested in that part
2023-11-17 08:54:34 <veltas      > Also might be a good template for anyone implementing zlib in forth
2023-11-17 08:54:39 <veltas      > Quite an important library
2023-11-17 09:03:54 <veltas      > Oh there's no compression, what am I talking about
2023-11-17 09:58:54 <veltas      > Ugh fed up with C code where people use sized integers for no good reason and it just creates more writing
2023-11-17 09:59:39 <veltas      > Who was it that said "this is how you write C in 202x" and recommend using sized types everywhere
2023-11-17 09:59:42 <veltas      > So I can slap them
2023-11-17 10:03:34 <Zarutian_iPad> sized integers?
2023-11-17 10:05:32 <GeDaMo      > uint32_t etc
2023-11-17 10:06:24 <Zarutian_iPad> right
2023-11-17 10:06:55 <Zarutian_iPad> well it is a recommended practice for mcu programming
2023-11-17 10:09:19 <Zarutian_iPad> but then you are often dealing with uint32tm_t and such
2023-11-17 10:09:52 <Zarutian_iPad> s/tm/bm/
2023-11-17 10:10:30 <Zarutian_iPad> so unsigned 32 bit bigendian modulo arithmetic integer
2023-11-17 10:10:52 <KipIngram   > I just answered a Quora question having to do with semiconductor physics.  Always makes me "think again" about how I'd like to write up something like Chuck's chip simulation tool.  It's just pretty amazing that by simply controlling geometry and doping levels of that stuff we can achieve so many different sorts of functionality.
2023-11-17 10:12:00 <veltas      > Zarutian_iPad: I write MCU programs all day and I happen to politely disagree
2023-11-17 10:12:08 <Zarutian_iPad> KipIngram: isnt that mostly where you get positive-negative diode-like junctions?
2023-11-17 10:12:30 <KipIngram   > Most of the time in electronics we thinking about wirin together pre-existing devices.  That's a bit like using a pre-existing library in software.  But this level gets it all down to shapes and doping concentrations.  It's like the "machine code" of hardware design.
2023-11-17 10:12:49 <KipIngram   > yes, the question I just answered pertained exactly to p-n junctions.
2023-11-17 10:12:54 <Zarutian_iPad> veltas: on something like esp32 or equiv in power?
2023-11-17 10:13:04 <veltas      > I'll have to do a writeup on this because it's not obvious why at outset
2023-11-17 10:13:11 <veltas      > But in practice it just makes a lot of things harder
2023-11-17 10:14:00 <veltas      > Main thing I use at moment is a Cortex M4 with about 128K of RAM, but this applies to anything that can handle C I would say
2023-11-17 10:14:14 <KipIngram   > p-type material is doped with something like boron, which is an electron short of properly filling out the silicon crystal lattice.
2023-11-17 10:14:32 <KipIngram   > n-type is doped with something like phosphorus, which has an excess electron.
2023-11-17 10:14:56 <KipIngram   > So those materials are still neutral, but they have these "charge carriers" (electron or "hole") that can float around  through the material.
2023-11-17 10:15:06 <Zarutian_iPad> veltas: so, not annoying things like pic14f or what the heck radon made back in the day
2023-11-17 10:15:19 <KipIngram   > When you jam pieces of each up against each other, thermal agitation causes the charge carriers to diffuse across the boundary.
2023-11-17 10:15:35 <KipIngram   > But that causes a net charge in that region, which creates an electric field that resists the diffusion.
2023-11-17 10:15:53 <KipIngram   > That comes to a steady state, with a little region with an electric field there near the junction.
2023-11-17 10:15:55 <veltas      > Zarutian_iPad: Yeah no
2023-11-17 10:16:23 <veltas      > I'll have to do a writeup but basically you just end up writing more and you are likely introducing portability issues without realising, because C is weird
2023-11-17 10:16:54 <veltas      > I would recommend limiting it to register and constrained memory struct usage
2023-11-17 10:17:05 <KipIngram   > Holes can flow long distances through p-type stuff, and electrons can flow long distances through n-type stuff.  So once you put enough voltage across it to cancel that built-in field, in the right direction, those flows will happen and they kind of "eat each other up" at the junction.
2023-11-17 10:17:32 <Zarutian_iPad> I see, well the thinking behind using sized integer is precisely to know which mcu or family of mcus you are targetting
2023-11-17 10:17:39 <KipIngram   > But if you try to make current flow the other way, you're trying to inject electrons into the p-type material and holes into the n-type material, and energy considerations cause those to just become part of the local lattice.
2023-11-17 10:17:42 <KipIngram   > No current.
2023-11-17 10:17:52 <veltas      > Zarutian_iPad: Yeah if it's non-portable from get-go there's no issue
2023-11-17 10:18:05 <veltas      > But I see people doing this in code that's meant to be portable and then it annoys me
2023-11-17 10:19:32 <Zarutian_iPad> veltas: I seen compiler or preprocesor directives that checks the size of uints and such to see if they are big enough or small enough for the portable code
2023-11-17 10:20:13 <veltas      > My concern isn't whether you get a nice error, it's just whether you're creating more writing and you supposedly care about portability
2023-11-17 10:20:50 <veltas      > It's in my article ideas list now
2023-11-17 10:20:58 <Zarutian_iPad> more writing as in keyboard traffic or?
2023-11-17 10:21:03 <veltas      > Yes
2023-11-17 10:21:14 <veltas      > It's something that deserves laying out carefully as a whole argument, not a good IRC talking point
2023-11-17 10:22:10 <veltas      > But if you want a preview it's mostly caused by format specifiers and integer promotion
2023-11-17 10:22:33 <veltas      > And uint_least32_t horror
2023-11-17 10:23:02 <Zarutian_iPad> you got RSI or something? This reminds me of an argument why you should not use {} or such because you need to chord two or three keys.
2023-11-17 10:23:30 <veltas      > It's about making mistakes as well as typing
2023-11-17 10:23:34 <veltas      > I think shorter code is easier to read and write generally, if it 'represents' the same thing
2023-11-17 10:23:49 <veltas      > It's quite important in my opinion to reduce visual clutter/noise
2023-11-17 10:23:57 <veltas      > I probably emphasise this more than most
2023-11-17 10:24:49 <Zarutian_iPad> hmm... no I am on the opposite of that. Too short code leads to hieroglyphics decipherment excercise
2023-11-17 10:25:02 <veltas      > I don't promote shortness for sake of shortness
2023-11-17 10:25:14 <veltas      > But extra casts I didn't need before are clutter IMO
2023-11-17 10:25:18 <Zarutian_iPad> or excessive whitespace use?
2023-11-17 10:25:31 <veltas      > I promise I'm tasteful and not ideological :P
2023-11-17 10:28:35 <Zarutian_iPad> I am preducing that you are one of those that uses tabs and sets their tabstops to 16 spaces
2023-11-17 10:28:49 <veltas      > I use tabs and we have 4 spaces mostly at work
2023-11-17 10:29:07 <veltas      > I try to use spaces for alignment when not at front of line
2023-11-17 10:29:35 <Zarutian_iPad> that is actually worse
2023-11-17 10:29:47 <veltas      > I think maybe don't assume things and I'll have to share this article with you if I ever get around to writing it
2023-11-17 10:29:55 <Zarutian_iPad> tab and three spaces
2023-11-17 10:29:59 <veltas      > It's not my choice, I'm just following the conventions
2023-11-17 10:30:21 <veltas      > I use three spaces with no tabulator characters when I write forth, or Ada.
2023-11-17 10:30:25 <Zarutian_iPad> look back at the verb I used
2023-11-17 10:31:09 <veltas      > I enjoy talking to you more when you're not being flippant
2023-11-17 10:34:00 <Zarutian_iPad> the thing is with these sized types in C is that often folks are using C like it is assembler and often other folk are using C as a portable language and both confuse the other
2023-11-17 10:48:46 <KipIngram   > Well, parallelizing that graph creation I mentioned earlier cuts the run time in half.  I still have to get the bundle ids first, as a first query, and that's taking about 2/3 of the time now.  The part that I paralleled went from about 18 seconds down to 3-4.
2023-11-17 10:49:01 <KipIngram   > I don't see any obvious way to speed up that eight second part.
2023-11-17 10:55:53 <KipIngram   > Oh, cool - I can speed it up.  I can restrict it to the latest range of bundle ids.
2023-11-17 10:56:07 <KipIngram   > Got the whole thing down to five and a quarter seconds.
2023-11-17 10:56:26 <olle        > http://www.jforth.org/JF-Books.html - some forth books
2023-11-17 10:56:39 <olle        > My Amiga 500 is in the basement tho :d
2023-11-17 11:02:29 <KipIngram   > Trip to the basement?
2023-11-17 11:02:46 <KipIngram   > 4.4 seconds.  I call that good enough.
2023-11-17 11:03:11 <KipIngram   > The parallelized data fetch is just three seconds now.
2023-11-17 11:43:58 <olle        > KipIngram: The basement is in another house.
2023-11-17 12:20:53 <zelgomer    > sometimes when writing a forth i go so far into the weeds that i forget how conventional words are supposed to work. what is your guys' preferred reference for this?
2023-11-17 12:22:56 <zelgomer    > it would be neat if there were some encyclopedia of common forth words and their various flavors from different dialects over the decades
2023-11-17 12:24:55 <GeDaMo      > There's the ANS standard https://forth.sourceforge.net/standard/dpans/dpansf.htm and some things like https://forth.sourceforge.net/mirror/comus/index.html
2023-11-17 12:27:18 <thrig       > if only you are using it, then what's wrong with a custom vocab?
2023-11-17 12:28:05 <zelgomer    > nothing in particular. it's hard to explain. i have a problem LOL
2023-11-17 13:06:07 <KipIngram   > zelgomer: I usually base my stuff on pretty old systems.  There's a book a guy named McCabe wrote called "Forth Fundamentals."  Volume 1 is a thorough "under the hood mechanics" coverage, more like FIG Forth than anything else.  Volume 2 is a glossary.  I most use those descriptions, but on the other hand I'm totally willing to make changes if they  make sense to me.
2023-11-17 13:06:40 <KipIngram   > Like, FIG had a particularly convoluted FIND operation.  I cleaned that up so that it always returns a single item - zero if not found and THE CFA if it is found.
2023-11-17 13:07:08 <KipIngram   > Pardon my capitalization - I'm not shouting.  My keyboard is getting funky.  :-(
2023-11-17 13:08:03 <thrig       > better funk than soul
2023-11-17 13:08:08 <KipIngram   > I've got a copy of the Forth 79 standard floating around the house somewhere.  I haven't even looked much at the current standard.
2023-11-17 13:08:09 <MrMobius    > veltas: wut
2023-11-17 13:08:33 <MrMobius    > I get it's not an IRC talking point but what do you do when int is 16 bit on one system and 32 bit on the other?
2023-11-17 13:09:12 <KipIngram   > Seems like it would depend on exactly what you're doing.
2023-11-17 13:10:09 <GeDaMo      > Convert! :P
2023-11-17 13:12:33 <KipIngram   > Yeah, seems most likely.  Converting 16->32 would present no problem; 32->16 might, depending on the values, but maybe less than you might expect.
2023-11-17 13:12:54 <KipIngram   > It's only "large positive" and "large negative" numbers that would throw issues.
2023-11-17 13:13:13 <KipIngram   > My system is a 64-bit system insofar as data goes.  64-bit stack cells, etc.
2023-11-17 13:13:27 <KipIngram   > But all of my definition "cells" are 32-bits, including literal values.
2023-11-17 13:13:44 <KipIngram   > So in theory I can't do the "extreme" literals.
2023-11-17 13:14:07 <thrig       > 16 to 32 could cause issues if code makes assumptions about where certain bits are, or there's a shift that gets the bits wrong
2023-11-17 13:14:13 <KipIngram   > But it's never been an issue; -2^31..(2^31-1) is an awfully big range.
2023-11-17 13:14:33 <KipIngram   > True, but that's not really "numeric" conversion anymore.
2023-11-17 13:15:05 <MrMobius    > ya agreed that it's less of a problem going 16 to 32 but I'm asking what happens the other way around. what do we do then if we aren't using int32 etc?
2023-11-17 13:15:54 <KipIngram   > I would generally just auto-convert in the obvious way, and try to catch the cases where that didn't really cover it and handle them case-by-case.
2023-11-17 13:16:40 <KipIngram   > re: thrig's case, if you've got a 32-bit interface port on some gadget, then that would have to become two separate 16-bit interface ports.
2023-11-17 13:16:57 <KipIngram   > so you might have to change bit masks and that kind of thing - it'd have to be thought through.
2023-11-17 13:18:34 <KipIngram   > That kind of thing could pop up; it would just depend on the system.  What I was trying to point out is that I doubt you really use many actual INTEGERS outside the range -32768 to 32767.
2023-11-17 13:18:46 <thrig       > openbsd needed a flag day to take the epoch from 32-bit to 64-bit
2023-11-17 13:18:58 <KipIngram   > We tend to use things like 0 or 1 or 4 etc.
2023-11-17 13:19:02 <KipIngram   > quite small integers.
2023-11-17 13:20:10 <MrMobius    > seems terrible
2023-11-17 13:20:29 <GeDaMo      > The research that lead to RISC found that most integer literals were small
2023-11-17 13:20:58 <MrMobius    > I don't want to be the one crawling through a huge codebase fixing things "case by case". sounds like Y2K again. will be interested to hear what veltas says
2023-11-17 13:22:59 <thrig       > 2037 should be a good year for consulting
2023-11-17 13:24:18 <KipIngram   > I'd think you'd automate it.  Scan through, convert the "obvious' ones.  I'd be pretty surprised if you had many that needed individual attention.
2023-11-17 13:24:46 <KipIngram   > Unless you've got a thrig situation where there's a pile of control registers with bit masks defining their bit meanings.
2023-11-17 13:25:03 <KipIngram   > Like all of those in the C termios stuff.
2023-11-17 13:26:35 <thrig       > PRNG that behave different with a bigger or smaller int
2023-11-17 14:31:59 <KipIngram   > Yes, for sure.
2023-11-17 14:34:55 <thrig       > also serialization, mailman used 32-bit ints and failed horribly when moved to a 64bit system
2023-11-17 14:36:25 <KipIngram   > I find the idea that an application should be expected to port effortlessly under such a major architecture change... less than reasonable.
2023-11-17 14:36:53 <KipIngram   > I'd expected it to be quite a pain, in fact.
2023-11-17 14:37:52 <Zarutian_iPad> 
ACTION hands KipIngram that Electron mostrousity

2023-11-17 15:31:18 <veltas      > I don't know how I manage to provoke these feelings but somehow I always manage to
2023-11-17 15:31:32 <veltas      > For the record I'm not telling anyone to fwrite their int's
2023-11-17 15:32:44 <thrig       > also zangband did something silly due to the 32-64 bit switch, like character creation got into an infinite loop
2023-11-17 15:33:01 <veltas      > I will have to write something about this int matter when I get a chance, but as I said I don't think IRC is a good place for this
2023-11-17 15:34:20 <veltas      > Instead I will transcribe my position and mail it to the journals and you can all post your counter-arguments in time for easter
2023-11-17 15:35:19 <veltas      > 
ACTION has a truly marvelous demonstration of this proposition that IRC messages are too narrow to contain

2023-11-17 16:13:09 <MrMobius    > lol
2023-11-17 16:13:22 <MrMobius    > I dunno if I want to read a journal article
2023-11-17 16:13:39 <MrMobius    > and somehow asking this seemed to come off like I don't know how types in C work
2023-11-17 16:14:56 <MrMobius    > veltas: I was hoping you might answer with a single line like instead of "int32_t var1, var2;" you would write "foo var1, var2;" and tell us what foo is
2023-11-17 16:43:59 <veltas      > Maybe I'm misinterpreting, but the commentary on what I've said sounds derisive and unfriendly, if anyone's genuinely interested to understand my position, and has good intentions towards me, then they can PM me and I will explain myself privately.
2023-11-17 18:13:40 <MrMobius    > veltas: sorry, no ill intentions towards you! legitimately curious and open minded. sorry if I caused any offense
2023-11-17 19:18:21 <KipIngram   > It's just flabbergasting to me the kind of stuff people will get on YouTube and talk about.  I try to mostly watch "conventionally educational" stuff, but now and again I'll let myself just ooze around, and wow you can find the most insane stuff.
2023-11-17 19:19:00 <KipIngram   > And there's always a vlogger who will talk with them and encourage them and oh and ah over it like it's most most amazing thing ever.
2023-11-17 19:19:41 <thrig       > p-HN_ICaCyM
2023-11-17 19:45:51 <MrMobius    > what flags do I need other than immediate and compile-only?
2023-11-17 19:59:07 <KipIngram   > Depends on your feature suite - that might be enough.
2023-11-17 19:59:49 <KipIngram   > I've used an additional one, but it was non-standard.
2023-11-17 20:00:18 <KipIngram   > I had a class of words that, when they were compiled, required an offset be compiled after then.  So I had a flag for that.
2023-11-17 20:01:09 <KipIngram   > Also, my current method for temporary words involves setting a flag to indicate that status, so that I know which ones to rip out of the list later.
2023-11-17 20:01:29 <KipIngram   > I'm going to do that in a different way this time, though, so I won't need such a flag.