2019-10-24 GnuCash IRC logs

00:30:54 *** storyjesse has joined #gnucash
01:33:48 *** sbluhm has joined #gnucash
01:33:49 *** ChanServ sets mode: +v sbluhm
01:36:12 *** Mechtilde has joined #gnucash
01:51:17 *** fell_laptop has joined #gnucash
01:51:18 *** ChanServ sets mode: +o fell_laptop
01:53:00 *** fell has quit IRC
01:55:40 *** storyjesse has quit IRC
01:56:13 *** Mechtilde has quit IRC
02:08:44 *** fell_laptop has quit IRC
02:08:47 *** fell has joined #gnucash
02:08:48 *** ChanServ sets mode: +o fell
02:24:23 *** pohly1 has joined #gnucash
02:39:25 *** fabior has joined #gnucash
03:02:05 *** fabior has quit IRC
03:20:01 *** sbluhm has quit IRC
03:23:41 *** sbluhm has joined #gnucash
03:45:37 *** gncbot has joined #gnucash
03:47:43 *** gjanssens has joined #gnucash
03:47:43 *** ChanServ sets mode: +o gjanssens
04:13:19 *** bertbob has quit IRC
04:15:24 *** bertbob has joined #gnucash
04:15:25 *** ChanServ sets mode: +v bertbob
04:23:22 *** omnireq has quit IRC
04:23:33 *** omnireq has joined #gnucash
04:23:33 *** ChanServ sets mode: +v omnireq
04:33:26 *** gggg has quit IRC
04:35:33 *** gggg has joined #gnucash
04:37:18 <mauritslamers> morning all... continuing from yesterday: fixing the difference between bill and invoice in the interface (https://bugs.gnucash.org/show_bug.cgi?id=743943). I created a fresh gnucash.pot file and noticed that there are a few strings not there. There is no "Print Bill" or "Print Voucher" and also no alternative for the tooltip of that action.
04:39:04 *** mr101freaking has joined #gnucash
04:41:56 <mauritslamers> What should I do there, create new strings for every type, or rather make it into "Print" and "Print the current document"
04:43:32 <mauritslamers> fell: gjanssens: what do you think would be best?
04:44:59 <fell> Hoi mauritslamers!
04:45:28 <fell> A few notes:
04:46:18 <fell> https://wiki.gnucash.org/wiki/GUI_Guidelines
04:46:33 <fell> https://wiki.gnucash.org/wiki/I18N
04:49:14 <fell> Because we want https://wiki.gnucash.org/wiki/GUI_Guidelines#Mnemonics_and_Accelerators
04:49:45 <fell> It would be "_Print ...
04:49:52 <mauritslamers> clear, I am just trying to change the existing ones.
04:50:19 <mauritslamers> fell: not in this case. The original doesn't contain the _ because it uses <primary>p
04:50:26 <mauritslamers> in the definition
04:51:08 <fell> Ah, oK.
04:51:51 <mauritslamers> so, what would be the preferred change here?
04:52:53 <fell> And then I would prefer parametrized strings "Print %s" as we have already the translations of the single words.
04:53:34 <mauritslamers> understood.
04:54:43 <fell> If there are languages which use different forms for subject and object, their translators can rise a bug and we can add the context.
04:55:10 <mauritslamers> parametrizing would make the implementation loads easier as well
04:58:02 *** Mechtilde has joined #gnucash
05:03:04 *** fabior has joined #gnucash
05:04:12 <fell> gjanssens: I am just wondering, why print is in the action menu and not as usual in the file menu.
05:05:04 <fell> AFAIK File->Print should print the content of the current window.
05:05:23 <mauritslamers> fell: if I am right the actions are used for both the menu as the toolbar buttons
05:05:50 <mauritslamers> in gnucash 3.7 mac the print option is not in the action menu
05:08:55 *** fabior has quit IRC
05:21:12 *** fabior has joined #gnucash
05:21:55 *** mr101freaking has quit IRC
05:26:06 <mauritslamers> feill: is it possible to use the action entry array (https://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome/gnc-plugin-page-invoice.c#L96) contain the parameters and apply them later through a call to gnc_plugin_update_actions (https://github.com/Gnucash/gnucash/blob/maint/gnucash/gnome/gnc-plugin-page-invoice.c#L422) ?
05:32:18 <fell> For backward compatibiliy I would init them with the default "Invoice" and adjust them.
05:36:10 <fell> BTW I would despite the primary add the accellerator _p for consistency.
05:36:26 <mauritslamers> ok, will do
05:36:53 <fell> The primary I can use without opening the menu.
05:37:05 <mauritslamers> The only downside to the defajt
05:37:31 <mauritslamers> the only downside of the default invoice means that those strings will be double: one time with invoice fixed and one time parametrized
05:38:00 <mauritslamers> but let's do it that way, the old way can be deprecated at some point.
05:38:20 <fell> And for a standard menu I would expect [alt]+[F]-[P] to print the curent document.
05:40:51 <fell> Why? format ("_Print %s", "Invoice")
05:42:43 <mauritslamers> fell: yes, but as those menu options are declared as static currently, I need a way to look up the first parameter to _()
05:42:52 <mauritslamers> or I have to define it twice
05:43:08 <mauritslamers> once in the static action array and once separately
05:43:37 <mauritslamers> I was looking for a way to look up the parametrized string from the action array
05:44:07 <fell> I just see, noopgettext(string) will not work with Parameters.
05:46:51 <fell> format ( _("_Print %s"), _("Invoice")) would work, not format ( N_("_Print %s"), N_("Invoice"))
05:47:58 <mauritslamers> yes, but that still requires defining the _Print %s part separately from the _Print Invoice in the static list
05:48:11 <mauritslamers> if that is ok, then I will do it that way :)
05:49:35 <fell> but somewhere later _(formated string) is called
05:52:18 <mauritslamers> hmm, looking at the gnc_plugin_update_actions() definitioin, that would not work for this case anyway, as it is to set a single value to a series of actions.
05:57:11 <mauritslamers> should I create a similar function to update single actions?
05:58:11 <fell> gjanssens knows this bits ways better.
06:08:12 <mauritslamers> fell: thanks, I will try to bother him about it then ;-)
06:14:07 *** fabior has quit IRC
06:19:10 <mauritslamers> gjanssens: are you available to help out a bit?
06:33:57 *** fabior has joined #gnucash
06:36:48 *** Jimraehl1 has joined #gnucash
06:39:34 *** Jimraehl1 has quit IRC
06:41:15 *** fabior has quit IRC
06:53:17 *** oozer has joined #gnucash
07:08:14 *** fell has quit IRC
07:08:24 *** fell has joined #gnucash
07:08:24 *** ChanServ sets mode: +o fell
07:10:41 *** fabior has joined #gnucash
07:15:12 *** monkeyjuice has joined #gnucash
07:15:23 *** fabior has quit IRC
07:16:09 *** monkeyjuice has quit IRC
07:32:50 *** monkeyjuice has joined #gnucash
07:37:17 *** monkeyjuice has quit IRC
07:40:49 *** storyjesse has joined #gnucash
07:44:32 <mauritslamers> gjanssens: fell: first attempt: https://github.com/mauritslamers/gnucash/tree/parametrized_translation_invoice_page
07:50:18 *** ecdhe has joined #gnucash
07:50:21 <fell> mauritslamers: https://wiki.gnucash.org/wiki/CodingStandard
07:52:10 <mauritslamers> fell: yes, have been trying to keep to the style as I got it from the source code. But I think I missed a few spots, will have a look at it
07:52:19 *** gggg_ has joined #gnucash
07:52:31 <mauritslamers> ah, and it fails compilation atm
07:53:16 <chris> mauritslamers: you've got some skill
07:53:33 <fell> In commit fefd24e you have once GncInvoiceType in the same line and once in a separate line asthe rest of the function.
07:54:18 <fell> Hi chris!
07:54:27 *** gggg has quit IRC
07:54:36 <chris> Hi fell
07:55:47 <mauritslamers> chris: thanks :-) but we still have to see whether my fix works :)
07:56:09 <mauritslamers> It has been a long time ago since I did C, and I never did it seriously neither
07:58:04 *** gggg_ has quit IRC
07:59:49 <mauritslamers> fell: the reason for the difference in fefd24e is that one is in the header file where types seems to always be on the same line. The other is in the C file where the type is on a separate line before the rest of the function.
07:59:59 <mauritslamers> I kept there to the style existing in the files
08:00:27 <fell> right, I had not the full context.
08:00:41 <mauritslamers> np :)
08:01:01 <mauritslamers> and another compilation fail...
08:01:08 <fell> The translation of the parametrization will not work.
08:01:48 <fell> N_() is noop-gettext. It marks a string for translation.
08:02:04 <mauritslamers> yes
08:02:11 <mauritslamers> I am also not parametrizing there
08:02:20 <mauritslamers> I am applying the format in the update function
08:02:22 <fell> The real translation is done by _() alias gettext()
08:02:45 <mauritslamers> as well as the translation btw
08:03:34 <mauritslamers> fell: specifically here: https://github.com/mauritslamers/gnucash/commit/d2949d15ab545a6a0179ec82003b8f9c06f43573#diff-8bd91e5a24f28088b263673ae92e2946R484
08:08:14 *** oozer has quit IRC
08:09:31 <mauritslamers> ah compilation error is because of naming conflct
08:14:19 <fell> OK, I missed something in my thinking.
08:15:56 <mauritslamers> fell: technique I used is to have the parametrization in the static definitions, then have a list of actions that need translations, walk through both, compare when they match (ie action needs translation), retrieve original label and tooltip values from the static definition, apply format and _() and set those values.
08:18:30 <fell> I am wondering, if we should add that to I18N page of the wiki. I believe there are more places where we should apply it.
08:24:09 <mauritslamers> let me first make it to work, as it doesn't atm. Most likely because of my rusty C.
08:25:45 <fell> NP
08:45:26 *** mr_sm11th has joined #gnucash
08:45:26 *** ChanServ sets mode: +v mr_sm11th
08:46:55 *** fabior has joined #gnucash
09:01:36 *** KaiForce has joined #gnucash
09:13:16 *** jonp has quit IRC
09:18:18 *** badger92 has quit IRC
09:23:34 <mauritslamers> fell: sorry to bother you again but where should I get a reference for that function format () from you mentioned earlier? or should I use g_printf instead?
09:26:43 <fell> There are so many *printf etc. formats, I don't know which is the best here.
09:27:08 <mauritslamers> hehe, me neither, that is why I was asking :)
09:27:53 <fell> What is else used in that module?
09:28:07 <mauritslamers> none, the only thing is _()
09:28:38 <mauritslamers> it is the parametrization which is the complexing factor.
09:29:27 <mauritslamers> I was already trying to find a function that is globally used for this, but couldn't find it
09:34:51 *** fabior has quit IRC
09:40:23 *** kael has joined #gnucash
09:40:23 *** ChanServ sets mode: +v kael
09:41:17 <fell> g_strdup_printf, sprintf, printf, ... depending on the context.
09:43:25 *** jervin has joined #gnucash
09:50:37 *** jervin has quit IRC
09:57:26 <mauritslamers> ok, using g_strdup_printf, it compiles now, lets see whether it will actually work
09:57:29 *** fabior has joined #gnucash
10:25:07 <mauritslamers> fell: looks like I made it work
10:26:08 <mauritslamers> I think I will create another branch to make things a bit more clean, as there are a few things that turn out not to be needed
10:26:51 <fell> Nice. yes that happens. :-)
10:26:57 *** omnireq has quit IRC
10:50:17 *** ArtGravity has joined #gnucash
10:50:18 *** ChanServ sets mode: +v ArtGravity
10:56:42 *** omnireq has joined #gnucash
10:56:42 *** ChanServ sets mode: +v omnireq
10:57:22 *** kael has quit IRC
11:01:33 *** Mechtilde has quit IRC
11:19:56 *** sbluhm has quit IRC
11:28:37 *** sbluhm has joined #gnucash
11:28:37 *** ChanServ sets mode: +v sbluhm
11:46:12 *** fabior has quit IRC
11:46:53 *** oozer has joined #gnucash
11:49:46 *** Gerd has joined #gnucash
12:03:45 *** storyjesse has quit IRC
12:06:22 *** guak has joined #gnucash
12:06:37 *** fabior has joined #gnucash
12:20:09 *** TommyT has joined #gnucash
12:20:09 *** ChanServ sets mode: +v TommyT
12:30:52 *** sbluhm has quit IRC
12:36:34 *** TommyT has quit IRC
12:47:40 *** fabior has quit IRC
12:48:59 <jralls> fell: "Print" and "Print %s" are different msgids. We have neither "Print %s" nor "Edit %s" as msgids at present.
13:05:30 *** kael has joined #gnucash
13:05:30 *** ChanServ sets mode: +v kael
13:09:41 *** calvinct has joined #gnucash
13:18:50 *** kael has quit IRC
13:20:51 *** karelk has quit IRC
13:21:53 *** karelk has joined #gnucash
13:24:48 <fell> jralls: yes, but we do not want Print/Edit/... Invoice/Bill/... each as separate string.
13:26:50 *** sbluhm has joined #gnucash
13:26:50 *** ChanServ sets mode: +v sbluhm
13:27:04 *** kael has joined #gnucash
13:27:04 *** ChanServ sets mode: +v kael
13:27:15 *** calvinct has quit IRC
13:27:29 *** karelk has quit IRC
13:37:16 *** Gerd has quit IRC
13:38:27 *** calvinct has joined #gnucash
13:42:23 *** calvinct has quit IRC
13:44:31 *** Mechtilde has joined #gnucash
13:48:58 *** karelk has joined #gnucash
13:50:45 <jralls> fell: I'm not convinced that's true. Just because we use the same words for edit and print in each of those cases in our Romance/Germanic languages doesn't mean that it's true for all languages.
13:52:33 <jralls> The general guidance in the gettext docs is to not compose msgids.
13:55:16 <fell> I remember there was one case, where we hat to distinguish messages to fulfil slavian grammars.
13:58:13 <jralls> Yeah, and Slavic languages are closer to Romance/Germanic than many: Basque, Chinese, and Tamil aren't even Indo-european.
14:04:27 <fell> It starts already with finn-ugrian and semitic languages, which are spoken in several EU member states.
14:17:15 *** Gerd has joined #gnucash
14:17:48 *** frakturfreak has joined #gnucash
14:20:49 *** Unhammer has quit IRC
14:24:22 *** Unhammer has joined #gnucash
14:24:22 *** ChanServ sets mode: +v Unhammer
14:30:13 <fell> And it are not only the menu entries (with mnemonics), there are similar msgs (without mnemonics) as tooltips.
14:35:37 *** sbluhm has quit IRC
14:40:22 *** Unhammer has quit IRC
14:44:36 *** Unhammer has joined #gnucash
14:44:36 *** ChanServ sets mode: +v Unhammer
14:51:05 *** mr_sm11th has quit IRC
15:02:24 *** User_ has joined #gnucash
15:02:54 <fell> If the grammars become too different, we should consider to return to e.g. "File->Print" with a tooltip "Print the currently selected document."
15:04:30 <fell> But for now, we should try Mauritslamers' approach.
15:07:37 <mauritslamers> Code is up here: https://github.com/mauritslamers/gnucash/tree/fix_bug_743943
15:08:27 *** User_ has quit IRC
15:09:54 <mauritslamers> verified by compiling and running.
15:10:12 <mauritslamers> fell: gjanssens: Thanks a lot for your great support!
15:11:29 <mauritslamers> What is the best way to offer it to the project? a PR on the github repo?
15:12:57 <gjanssens> mauritslamers: you're welcome :)
15:13:17 <gjanssens> Yes a PR is the best way. That makes it easy to review
15:13:24 <mauritslamers> perfect
15:13:34 <gjanssens> (only back on my pc just now... afk most of the day)
15:14:32 *** bertbob has quit IRC
15:18:17 *** Mechtilde has quit IRC
15:18:28 <mauritslamers> gjanssens: still one question. I just noticed that I didn't add a direct include to gncInvoice.h to get access to the enum of the invoice types. It still runs though, so somehow it is available.
15:18:40 <mauritslamers> Do you think it would be good to add that #include anyhow?
15:18:59 *** calvinct has joined #gnucash
15:19:00 <gjanssens> mauritslamers: yes
15:20:23 *** calvinct has quit IRC
15:23:50 <gjanssens> fell, jralls: https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/38874577-save-report-configurations-the-style-sheets-and goes back to the discussion I had to defer last week (or was it two weeks ago already ?)
15:24:30 <gjanssens> What I have wanting to add to that discussion is a comparison with a spreadsheet
15:25:17 <gjanssens> If we have a spreadsheet and include a chart of the numbers you manage in that sheet, we take it for granted the spreadsheet remembers how we configured that chart
15:25:28 <gjanssens> (size, colors, data series,...)
15:25:50 <gjanssens> I think for a gnucash end user the expectation is the same.
15:26:30 <mauritslamers> PR created
15:26:41 <gjanssens> We as devs can have a mental model about keeping data and presentation separate, but IMO shouldn't overdo that.
15:27:24 <gjanssens> Especially not if it goes against common user expectation.
15:27:40 <gjanssens> mauritslamers: thanks!
15:28:29 <gjanssens> I was going to suggest that column widths and stuff could be outside of the data, but then it occurred to me even that is saved inside a spreadsheet!
15:28:42 <gjanssens> (called for supper)
15:29:20 <fell> My libreoffice has always the wrong page layout. :-(
15:30:50 <fell> Documents sent by email look ugly because both machines have different fonts installed, ...
15:32:12 <mauritslamers> as an outsider, I would think there are two layers involved: the data being the data, and the presentation remembering how it displayed the data.
15:32:46 <mauritslamers> Because the data could be switched out and different data switched in and it should still keep the same layout
15:33:08 <fell> AFAIK all office packages know the concept of templates, which are also stored in different directories.
15:33:37 <mauritslamers> yes, but even then: the spreadsheet itself is not so much a data format as a presentation format
15:35:38 <mauritslamers> it needs to be noted that I don't know what the discussion is about exactly... :)
15:36:21 <fell> I wish keep saved reports separate, so that different users can have their specific adjusted reports.
15:39:11 <fell> Gjanssens wishes to integrate them in the gnucash file, because some users are missiing their saved report options after they copied their gnucash file on a different computer.
15:40:21 <mauritslamers> ah, that is interesting. To me both options make sense :)
15:45:02 <fell> Perhaps we should speed up the switch to a full featured SQL database, wjere one can define different views and rights for different users?
15:46:06 <mauritslamers> fell: that also defintely makes sense. it would make accessing the same "database" from multiple computers easier
15:47:09 <mauritslamers> I am also wondering whether it makes sense then to switch to a different GUI engine... I must admit that doing this PR of fixing the interface reminded me why I don't like user interfaces written in C or C++ :-)
15:48:18 <mauritslamers> but being the project lead of a (ok-bit oldfashioned) JS framework specifically for these kind of apps might be the cause ;-)
15:49:13 <fell> The reason is GC dates back in the previous millenium.
15:50:17 <mauritslamers> I am very interested to see how GC would look like as a webapp / electron app
15:50:32 <fell> The switch from motifbto GTK was really a progress at that time.
15:53:42 <fell> Now there happens somthing "under the hoot" from C + GObject to C++.
15:55:23 <fell> After that it will be easier to change the GUI.
15:56:15 *** TommyT has joined #gnucash
15:56:15 *** ChanServ sets mode: +v TommyT
15:56:31 <mauritslamers> to be very honest, I doubt that C++ is a better way of writing UI than C...
15:58:41 <fell> Currently you are free to use Guile (Scheme) or Python for your own extensions.
15:59:56 *** bertbob has joined #gnucash
15:59:57 *** ChanServ sets mode: +v bertbob
16:00:07 <mauritslamers> Technically, it is possible to write a complete different front-end to gnucash, yes? Simply interfacing with the libgnucash would do, right?
16:00:19 <fell> yes
16:01:32 <mauritslamers> nice, even a REST interface :)
16:02:36 <fell> I believe, chris knows more about Gnucash and REST.
16:02:49 <jralls> Sorry I missed out on the early part of the discussion, I had some chores.
16:04:05 <fell> https://lists.gnucash.org/logs/2019/10/24.html
16:04:52 <jralls> fell, I know where the logs are. ;-) But no need, my client was running and captured all of the discussion.
16:05:35 <jralls> The GUI only dates back to the aughties. Only the xacc parts are 20th century.
16:06:40 <jralls> REST is a necessary evil in the web world, and requires all sorts of pretzel logic to maintain state in an application. CRUD, on the other hand, is a useful way of thinking about any data-driven application.
16:08:15 *** kael has quit IRC
16:09:35 <jralls> mauritslamers: C++ is generally a better way of writing anything than C, but it's a complex language that takes a lot of study to be able to write well and fluently.
16:11:38 <jralls> AFAIK Gtk is the only widely-used GUI written in C and it's built on a hacked-together sort-of-OO foundation called GObject.
16:16:08 *** pohly1 has quit IRC
16:20:20 <jralls> fell, gjanssens, Wm Tarr suggested in a bug report last spring that we could combine the data and presentation stuff in separate files contained in a single archive. Easy on MacOS (just make it a bundle, looks like a single file to the user), not so much on Linux/BSD or Windows.
16:23:11 *** mr_sm11th has joined #gnucash
16:23:11 *** ChanServ sets mode: +v mr_sm11th
16:25:34 <gjanssens> jralls: that's not really an option if our intention is to become a db application.
16:25:59 <jralls> For another user's viewpoint there's https://gnucash.uservoice.com/admin/v3/suggestions/38874577/.
16:26:31 <gjanssens> mauritslamers: I don't think we plan to write our GUI in C++ ourselves. I would still use a gui framework, some of which may be written in C++ though.
16:26:52 <jralls> gjanssens: As fell pointed out last week we can just set up some more tables for the SQL backend.
16:27:10 <gjanssens> jralls: that's the uservoice request I referred to earlier in this thread
16:27:55 <gjanssens> Sure, and how is that different from having a set of kvp's in an xml file ?
16:28:13 <gjanssens> (Have to interrupt the conversation again. Bedtime :)
16:28:15 <mauritslamers> jralls: my background is SproutCore, a Cocoa like framework in a webbrowser, used by Apple originally for their MobileMe setup and later (and still) also for iWorks.com
16:29:22 <mauritslamers> REST is definitely a bad way to do application logic and state
16:29:23 <jralls> gjanssens, The difference is that KVP is an ugly hack. The analog to more tables is more top-level elements.
16:29:41 <jralls> gjanssens, good night!
16:29:46 *** tortoise has quit IRC
16:29:54 <gjanssens> Well, sure. My main point was that if we can store the data in db somehow, we can also in an xml file
16:29:56 <gjanssens> Night!
16:30:03 *** gjanssens has quit IRC
16:32:02 <mauritslamers> to me C++ is more and more a collection of languages where many the different approaches from other programming languages are bolted on
16:32:55 <jralls> No, C++ is a carefully unified language that makes possible programming in multiple paradigms.
16:33:41 <jralls> And in the last 10 years has improved greatly by the collapse of the "no syntactic sugar" wing of the standards committee.
16:35:03 <jralls> But all of those paradigms have been in the language since before the ISO standard even got started: Jim Coplien wrote C++ Programming Idioms almost 30 years ago.
16:35:21 <mauritslamers> lambda also?
16:35:42 <jralls> lambda is syntactic sugar for function object.
16:35:56 <jralls> And yes, function object was in Coplien's book.
16:36:03 <mauritslamers> cool
16:36:12 <fell> Bedtime for me,too.
16:36:20 <jralls> Gnight!
16:36:24 <mauritslamers> night!
16:36:45 <fell> Have still funW
16:37:17 <jralls> I should add that lambda is very welcome syntactic sugar indeed. It's a much more natural way to create a function object, especially inline.
16:39:15 <mauritslamers> jralls: as already said, I am more JS (and Scheme) minded :-) I today lost at least a day in fixing compiler errors about things that IMHO should not have mattered at all :-)
16:39:50 <mauritslamers> I know there can be an advantage in strict typing, but for interface code it just doesn't make sense to me...
16:39:56 <mauritslamers> interface code => UI code
16:43:40 <jralls> I'm also the Mac maintainer for Gramps, a genealogy program written in Python that uses Gtk as its backend. You wouldn't believe the number of crasher bugs we get where the error is "type xxxx doesn't have a yyyy attribute". That's a direct result of a combination of duck typing and interpreted code: All errors happen at runtime, so the only way to keep bugs away from users is testing. There are very few projects with 100% code coverage, so I'm a
16:43:41 <jralls> fan of strict typing and getting the compiler to do as much as possible with lots of warnings.
16:44:14 <jralls> s/backend/GUI framework/
16:47:27 <mauritslamers> Sloppy work exists everywhere :-)
16:48:10 <mauritslamers> and it is human to make mistakes, definitely
16:48:56 <mauritslamers> I feel that strict typing does not help much in preventing testing
16:49:19 <mauritslamers> it just protects against one specific kind of error, and usually not all the others.
16:50:43 <mauritslamers> BTW I wouldn't like this conversation to end up in a fight over strict typing and dynamic typing... :)
16:51:43 <mauritslamers> There is one remark by Douglas Crockford which I found interesting about strict typing: he was telling about how at some point he got a error report from his Java JSON parser.
16:52:12 <mauritslamers> the error was an overflow on an int pointing at the error location in the json.
16:53:45 <mauritslamers> His remark on it was that this kind of typing can costs a lot of developers brainpower without much gain, and which could still lead to errors.
16:55:57 <jralls> Sorry, that doesn't track. Do you mean because Scheme and JS use multi-precision ints by default that they would have ignored the problem and allowed the JSON to create whatever size number it wants? That's somehow a good thing?
16:56:13 *** mr_sm11th has quit IRC
16:57:33 *** calvinct has joined #gnucash
16:58:36 <mauritslamers> no, his reasoning was that having to think what kind of type of number your error location indicator uses was too taxing, and forced the developer to look 10+ years in the future to thnk how it might be used then in order not to run into problems.
16:59:06 <mauritslamers> He didn't say JS or Scheme did that better, rather the opposite.
16:59:43 <jralls> Sorry, I guess I don't understand the underlying problem then.
17:01:01 <mauritslamers> the error he got was 10 years after he wrote the JSON parser in Java. He used an int to give the location of the error if an error was found. The parser failed as someone used a 2+GB JSON file with an error, where the error location was larger than the int could address.
17:02:47 <mauritslamers> His story was that having to think at all about the possible size of a json file in order to define what kind of type the error location should be, is a not clever use of developer brain power.
17:03:02 <mauritslamers> If there would have been a single Number type, it would never have been a problem.
17:03:14 <mauritslamers> He then continues that while JS has a single Number type, it is the wrong one.
17:04:29 <jralls> OIC, the index into the JSON file overflowed. Amusing.
17:04:48 <mauritslamers> the error index overflowed indeed
17:04:58 <mauritslamers> trying to find the video where he was talking about it
17:05:02 *** ArtGravity has quit IRC
17:05:45 <jralls> A single number type would be a bad idea, floating point and integer are very different animals.
17:06:13 <mauritslamers> he also indicates that floating point is the wrong standard
17:06:40 <mauritslamers> because it doesn't cope well with human expectations: the famous 0.1 + 0.2 != 0.3
17:08:08 <jralls> So there are two sides to that. I guess you're referring to the problem that 1/10 can't be exactly represented in binary.
17:09:37 <mauritslamers> he was telling about that originally there were two competing standards for floating point.
17:10:41 <mauritslamers> one for business and one scientific. The scientific won, and because the floating point as we know it.
17:10:54 <jralls> But there's also the issue that when dealing with real-world measurements floating point numbers are inherently approximate.
17:11:59 <jralls> Business doesn't use or want floating point. Business wants fixed-point BCD.
17:12:41 <mauritslamers> http://www.dec64.com/ is the type he was proposing
17:17:09 *** Gerd has quit IRC
17:17:11 *** frakturfreak has quit IRC
17:19:37 *** Hexiloo has joined #gnucash
17:23:08 <mauritslamers> jralls: this is a bit of one of the videos where he points out what he thinks is wrong with floating type: https://youtu.be/99Zacm7SsWQ?t=2151
17:23:24 <mauritslamers> it is only a few minutes, afterwards he goes into different directions.
17:23:40 <mauritslamers> still not the video where he tells about the json error though
17:23:44 <jralls> Oh, I understand from www.dec64.com where he's coming from. It's such an obvious approach that there must be a reason why it doesn't already exist.
17:24:18 *** calvinct has quit IRC
17:24:54 *** calvinct has joined #gnucash
17:26:41 <jralls> Or maybe he doesn't understand floats as well as he thinks: IEEE 754 also uses two ints the same way: https://en.wikipedia.org/wiki/IEEE_754
17:28:50 *** TommyT has quit IRC
17:31:07 <mauritslamers> this is the bit about the bug story: https://youtu.be/PSGEjv3Tqo0?t=1576
17:31:38 *** calvinct has quit IRC
17:39:03 *** calvinct has joined #gnucash
17:53:26 *** calvinct has quit IRC
17:59:57 *** fell has quit IRC
18:02:12 *** guak has quit IRC
18:02:26 *** guak has joined #gnucash
19:11:11 *** omnireq has quit IRC
20:22:27 *** omnireq has joined #gnucash
20:27:26 *** guak has quit IRC
21:30:50 *** oozer has quit IRC
21:34:41 *** fell has joined #gnucash
21:34:41 *** ChanServ sets mode: +o fell
21:58:46 *** badger92 has joined #gnucash
22:01:47 *** badger92 has quit IRC