> 1561075450 927607 PRIVMSG #esoteric :14[[07User:Salpynx/Sator Resatus14]]4 10 02https://esolangs.org/w/index.php?diff=63589&oldid=63588 5* 03Salpynx 5* (+1008) 10The Waterfall Model compilation sketch
> 1561075642 462256 PRIVMSG #esoteric :14[[07User:Salpynx/Sator Resatus14]]4 10 02https://esolangs.org/w/index.php?diff=63590&oldid=63589 5* 03Salpynx 5* (+2) 10/* The Waterfall Model */ bug fix (there may be more)
< 1561075929 151285 :sombrero!bf7e35d0@gateway/web/freenode/ip.191.126.53.208 QUIT :Ping timeout: 256 seconds
> 1561079645 779053 PRIVMSG #esoteric :14[[07User:Salpynx/Sator Resatus14]]4 10 02https://esolangs.org/w/index.php?diff=63591&oldid=63590 5* 03Salpynx 5* (+1095) 10/* Examples */ cellular automata, aspirational for now
< 1561079918 318994 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Read error: Connection reset by peer
< 1561081195 124191 :salpynx!794954f8@gateway/web/freenode/ip.121.73.84.248 JOIN :#esoteric
< 1561086610 668362 :xkapastel!uid17782@gateway/web/irccloud.com/x-milravllywprdwbu QUIT :Quit: Connection closed for inactivity
< 1561086651 931126 :adu!~ajr@pool-173-73-86-145.washdc.fios.verizon.net JOIN :#esoteric
< 1561087332 465466 :Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net QUIT :Read error: Connection reset by peer
< 1561087356 897114 :Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net JOIN :#esoteric
< 1561087763 994122 :Frater_EST!~adrianbib@wsip-68-15-198-210.ok.ok.cox.net JOIN :#esoteric
< 1561094327 84989 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 245 seconds
< 1561094426 697359 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric
< 1561094712 606714 :FreeFull!~freefull@defocus/sausage-lover QUIT :
< 1561094714 525531 :adu!~ajr@pool-173-73-86-145.washdc.fios.verizon.net QUIT :Quit: adu
< 1561098952 167107 :imode!~imode@unaffiliated/imode QUIT :Ping timeout: 245 seconds
< 1561099191 485853 :clog!~nef@bespin.org JOIN :#esoteric
< 1561099658 662330 :uplime!uplime@learnprogramming/staff/nchambers NICK :major_uplime
< 1561101579 559030 :AnotherTest!~turingcom@d51A4B8E1.access.telenet.be JOIN :#esoteric
< 1561102249 234961 :atslash!~atslash@static.231.107.9.5.clients.your-server.de QUIT :Quit: Leaving
< 1561102415 781228 :atslash!~atslash@static.231.107.9.5.clients.your-server.de JOIN :#esoteric
< 1561102790 774513 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :  The answer become "Isosets", a foundational mathematical theory, where not only "sets" can contain several "elements", but "elements" can belong to several "sets".
< 1561102800 831422 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :
ACTION scratches head

< 1561103251 963855 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What a bizarre set theory.
< 1561103486 503452 :myname!~myname@ks300980.kimsufi.com PRIVMSG #esoteric :i always thought elements can belong to several sets all along
< 1561104109 694680 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: hi ski
< 1561104125 526473 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So I was thinking about function arguments.
< 1561104191 33096 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Instead of currying multi-argument functions, which requires a bunch of complicated features like closures, it seems reasonable to me for a C-level language to have only one-argument functions that take tuples (like in maths).
< 1561104195 908505 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator QUIT :Quit: Blame iczero something happened
< 1561104197 357718 :moony!moony@hellomouse/dev/moony QUIT :Quit: Bye!
< 1561104263 525862 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You could also have each function implicitly define a struct for its arguments.
< 1561104296 443399 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Say [x,y,z] is tuple/struct literal syntax. The equivalent of "int f(char x, bool y)" would be a function taking a struct { char x; bool y; } argument.
< 1561104307 380177 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :yes
< 1561104329 732544 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can have keyword arguments by allowing a struct literal syntax, so you can write [x='a', y=true] or something and it extends to both structs and functions automatically.
< 1561104344 1794 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can also support default arguments with default struct value members and so on.
< 1561104417 283817 :Bowserinator!Bowserinat@hellomouse/dev/Bowserinator JOIN :#esoteric
< 1561104421 429660 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, the language feature I had in mind for making this work isn't quite well-specified, but it's something like flexible/dynamic compile-time values and statically runtime values.
< 1561104435 14615 :moony!moony@hellomouse/dev/moony JOIN :#esoteric
< 1561104474 341994 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :E.g. some languages support integer literals that are arbitrary-size, but when you use a literal at a particular type, it turns into a value of that type and at that point can't be coerced further.
< 1561104550 934216 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Similarly I was thinking that [x,y,z] or [x,b=y,c=z] are "compile-time literals" that can be coerced into tuples and structs and so on, but you can't coerce a tuple value into a struct.
< 1561104611 289253 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This kind of system seems like it'd be pretty nice for making multi-argument and keyword/default argument functions work.
< 1561104617 143167 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Do you know of anything like it?
< 1561104642 90101 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, "flexible/dynamic compile-time values and statically runtime values" sounds backwards to how things are usually described, elaborate ?
< 1561104664 704192 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :can you coerce a record into a tuple ?
< 1561104697 755236 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :would the default values be part of the type ?
< 1561104700 867584 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I should have better names for these things.
< 1561104719 642328 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes, I'm imagining default values being part of a type (like struct T { int a = 5; }; in C++11).
< 1561104803 83080 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, so you can have records with the same fields (of the same types), but different defaults
< 1561104816 170796 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You could have struct A { int x; }; struct B { int x; };, which are distinct types, and the compiletime value [x=5] could be used as either one.
< 1561104824 306525 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure, they're distinct types.
< 1561104829 904539 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :does this entail nominal rather than structural matching of record types ?
< 1561104841 725601 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Just like you can write void f(int x, char y = 'a'); void g(int x, char y = 'b'); in C++.
< 1561104845 86170 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(aka heavy-weight vs. light-weight)
< 1561104874 482033 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm not sure what you mean.
< 1561104932 301437 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :what if you want to pass on a record that one function returns, to another. would both have to refer to the same, named, type, or is it enough that the types structurally match ?
< 1561104962 918283 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm not sure what you mean by "record".
< 1561104978 223846 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :the same as "struct"
< 1561104985 227678 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :OK, so a specific type.
< 1561105014 851337 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you want to write f(g(x)), where g returns a record and f takes a record, they'd have to be the same type.
< 1561105035 857682 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I guess that's not ideal.
< 1561105082 17883 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But it might make sense, as long as f can explicitly specify that it takes a tuple or a specific type or something, to allow them to match.
< 1561105125 740027 :b_jonas!~x@catv-176-63-24-146.catv.broadband.hu QUIT :Quit: leaving
< 1561105139 986623 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Writing f(g(x)) for multiargument f isn't supported in most languages at all -- I'm not sure how important it is for cases where f and g don't know about each other.
< 1561105157 806348 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, and you could presumably define an operator that explicitly takes a record into a "compiletime literal".
< 1561105191 6484 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So it'd turn a value x of type struct A { int a; char b; }; into the record [a=x.a, b=x.b] or [x.a, x.b] or something.
< 1561105200 872380 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Then you could write f(!g(x)) or something like that.
< 1561105277 663622 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(I have some other ideas that might use this compiletime-only value in a pretty foundational way. But I'm still not sure how well it would work.)
< 1561105351 243686 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, so `[x = 5]' is like an initializer, or a compound literal, that can be used to construct a value of some type (in an appropriate context), rather than itself specifying the value itself ?
< 1561105409 655706 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think so? I'm not quite sure what you mean.
< 1561105425 534388 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(i think you have something like that in Pascal and Ada, where you declare named types which act roughly as `newtype's, and you can initialize variables holding them with ones coming from the representation type. i don't recall the details well enough)
< 1561105435 992672 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm imagining it as a standalone value that can exist at compiletime but can't be assigned to a runtime variable (there's no memory layout for it etc.).
< 1561105473 417385 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :A macro/compiletime function can presumably operate on these things, but not a runtime function.
< 1561105478 287035 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :i mean that `[x = 5]' itself wouldn't have a well-defined type, but given a context of some tuple or record type, it can be used to construct a value of that type ?
< 1561105497 307079 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And coercions from these literals to records can be statically checked at the time they're used.
< 1561105501 799146 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right.
< 1561105924 220558 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(in C, you can't write `{4,"foo"}' as a value, but you can write `struct {int n; char *s} str = {4,"foo"};', and you can write a compound literal `(struct {int n; char *s}){4,"foo"}', even replacing `{4,"foo"}' with `{.n = 4,.s = "foo"}')
< 1561105960 802426 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes.
< 1561105965 303418 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(hm, the former being called a "designated initializer", apparenty)
< 1561105983 631253 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :C99's compound literals/designated initializers are quite nice.
< 1561106121 947250 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :<ski> can you coerce a record into a tuple ?
< 1561106174 197985 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think the answer is no, if tuple types exist.
< 1561106200 367375 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(Tuple is just a special struct with no field names, or field names .0 .1 etc.?)
< 1561106207 936203 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :
ACTION nods

< 1561106238 984594 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so how would this `!' work ?
< 1561106277 193447 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm not sure, I just thought of it.
< 1561106324 869076 :arseniiv_!~arseniiv@136.169.209.52 JOIN :#esoteric
< 1561106386 206670 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :fair enough
< 1561106397 262205 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You can say that it mechanically turns a value of a record type into a literal.
< 1561106430 163461 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :struct { int x; char y; } v; "!v" -> [x=v.x, y=v.y]
< 1561106456 52698 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so `[a=x.a, b=x.b]' rather than `[x.a, x.b]' then, i suppose
< 1561106460 739218 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :aye
< 1561106470 586617 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If you give an explicit name to the literal->record coercion, say @, then @!v is equal to v. Or something.
< 1561106826 709913 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :
ACTION nods

< 1561109237 806988 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: But if [a=x, b=y] is a compiletime value, it's a pretty odd one.
< 1561109249 555721 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Because x and y are runtime values.
< 1561109272 322452 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe that's not that odd. But it's not what people usually mean by "compile-time values", I think.
< 1561109908 126254 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :partially static value
< 1561109943 613647 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(cf. staged programming, binding time analysis, partial evaluation)
< 1561113632 40523 :xkapastel!uid17782@gateway/web/irccloud.com/x-ehceqwybegohziqx JOIN :#esoteric
< 1561117017 250441 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric
< 1561119303 607813 :arseniiv_!~arseniiv@136.169.209.52 NICK :arseniiv
< 1561119913 841843 :Frater_EST!~adrianbib@wsip-68-15-198-210.ok.ok.cox.net QUIT :Ping timeout: 258 seconds
> 1561122461 134415 PRIVMSG #esoteric :14[[07User:Salpynx/Sator Resatus14]]4 10 02https://esolangs.org/w/index.php?diff=63592&oldid=63591 5* 03Salpynx 5* (+911) 10/* Higher dimensions */ tesseract skeleton construction attempt
< 1561123805 508784 :xkapastel!uid17782@gateway/web/irccloud.com/x-ehceqwybegohziqx QUIT :Quit: Connection closed for inactivity
< 1561123945 759206 :Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net PRIVMSG #esoteric :Now that I recognize this conversion math as a rotation, it looks a lot easier to reverse
< 1561123979 290114 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Which conversion math?
< 1561123994 806887 :Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net PRIVMSG #esoteric :https://gist.github.com/Sgeo/4c58d69fa4375e4f2f3592e1f9c6eb0e
< 1561124036 13305 :Taneb!~Taneb@runciman.hacksoc.org PRIVMSG #esoteric :Ah, neat
< 1561124103 693535 :Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net PRIVMSG #esoteric :Blah // Perform a rotation about z: Roll. We only need x, so y isn't transformed.
< 1561126308 231863 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 JOIN :#esoteric
< 1561126310 490726 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :`olist 1168
< 1561126311 93598 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :olist 1168: shachaf oerjan Sgeo FireFly boily nortti b_jonas
< 1561126312 5700 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :that was quick
< 1561127411 624100 :xkapastel!uid17782@gateway/web/irccloud.com/x-omddhcttlkgwanqf JOIN :#esoteric
< 1561127949 155905 :salpynx!794954f8@gateway/web/freenode/ip.121.73.84.248 QUIT :Ping timeout: 256 seconds
< 1561128178 762390 :imode!~imode@unaffiliated/imode JOIN :#esoteric
< 1561129141 606662 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 QUIT :Remote host closed the connection
> 1561129808 810503 PRIVMSG #esoteric :14[[07Talk:Rook14]]4 N10 02https://esolangs.org/w/index.php?oldid=63593 5* 03A 5* (+366) 10Please Psecify
> 1561129847 815190 PRIVMSG #esoteric :14[[07Rook14]]4 M10 02https://esolangs.org/w/index.php?diff=63594&oldid=63585 5* 03A 5* (+2) 10Bad link.
> 1561129863 8255 PRIVMSG #esoteric :14[[07Talk:Rook14]]4 M10 02https://esolangs.org/w/index.php?diff=63595&oldid=63593 5* 03A 5* (+0) 10Bad link.
> 1561130003 564073 PRIVMSG #esoteric :14[[07Iota14]]4 M10 02https://esolangs.org/w/index.php?diff=63596&oldid=53227 5* 03A 5* (+293) 10
> 1561130200 393076 PRIVMSG #esoteric :14[[07Talk:Rook14]]4 M10 02https://esolangs.org/w/index.php?diff=63597&oldid=63595 5* 03A 5* (+415) 10/* Please specify */
> 1561130270 708939 PRIVMSG #esoteric :14[[07Talk:Rook14]]4 M10 02https://esolangs.org/w/index.php?diff=63598&oldid=63597 5* 03A 5* (+20) 10Bad link again.
< 1561135171 473223 :b_jonas!~x@catv-176-63-24-12.catv.broadband.hu JOIN :#esoteric
< 1561135782 188080 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric
< 1561137442 305914 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric
< 1561137647 789615 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 268 seconds
< 1561137648 545684 :Lord_of_Life_!~Lord@unaffiliated/lord-of-life/x-0885362 NICK :Lord_of_Life
< 1561138186 310660 :moei!~moei@softbank221078042071.bbtec.net JOIN :#esoteric
< 1561142959 297428 :Vorpal_!~Vorpal@unaffiliated/vorpal QUIT :Ping timeout: 246 seconds
< 1561143327 421575 :Vorpal!~Vorpal@unaffiliated/vorpal JOIN :#esoteric
< 1561146347 974653 :adu!~ajr@pool-173-73-86-145.washdc.fios.verizon.net JOIN :#esoteric
> 1561147728 534005 PRIVMSG #esoteric :14[[07Iota14]]4 10 02https://esolangs.org/w/index.php?diff=63599&oldid=63596 5* 03Ais523 5* (-293) 10Undo revision 63596 by [[Special:Contributions/A|A]] ([[User talk:A|talk]]): copyright violation (this content is copied from a CC-by-sa source)
> 1561147850 553668 PRIVMSG #esoteric :14[[07Special:Log/delete14]]4 revision10 02 5* 03Ais523 5*  10Ais523 changed visibility of a revision on page [[02Iota10]]: content hidden: Copyright violation
< 1561149860 901517 :major_uplime!uplime@learnprogramming/staff/nchambers NICK :uplime
< 1561150205 585750 :xkapastel!uid17782@gateway/web/irccloud.com/x-omddhcttlkgwanqf QUIT :Quit: Connection closed for inactivity
< 1561150564 936229 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Is there the possibility to guess at the proper values of rounded values in a JPEG file in order to try to improve the quality of a JPEG picture without altering the file?
< 1561152838 593679 :AnotherTest!~turingcom@d51A4B8E1.access.telenet.be QUIT :Ping timeout: 272 seconds
< 1561153367 478934 :b_jonas!~x@catv-176-63-24-12.catv.broadband.hu PRIVMSG #esoteric :zzo38: probably only when the JPGE is of a very bad quality
< 1561153510 455325 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Maybe you are correct, but still, how might be done?
< 1561153604 844278 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :You could build a model of what uncompressed pictures are like, and then twiddle with the rounding to make the result fit the model better.
< 1561153645 110215 :b_jonas!~x@catv-176-63-24-12.catv.broadband.hu PRIVMSG #esoteric :zzo38: look at neighboring blocks, see what doesn't cause an ugly edge between blocks
< 1561153699 243150 :b_jonas!~x@catv-176-63-24-12.catv.broadband.hu PRIVMSG #esoteric :zzo38: and when there's a clear boundary of some object, try to make it mostly straight and sharp and at the same location on all three plains
< 1561153760 207632 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :OK, those are ideas to do
< 1561153810 601193 :b_jonas!~x@catv-176-63-24-12.catv.broadband.hu PRIVMSG #esoteric :it might be an AI-complete task in general, because after some basic improvements, you have to recognize what the image is trying to depict
< 1561153837 267682 :xkapastel!uid17782@gateway/web/irccloud.com/x-ktisqbzmajjjwdgv JOIN :#esoteric
< 1561153891 754571 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Yes, that is what it might be.
< 1561157787 930605 :arseniiv_!~arseniiv@136.169.202.147 JOIN :#esoteric
< 1561157984 935004 :arseniiv!~arseniiv@136.169.209.52 QUIT :Ping timeout: 248 seconds
< 1561157996 934312 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Finally now they are adding into SQLite a SQLITE_DBCONFIG_NO_DQS option, but maybe there should be some way to set the that option at compile time too rather than only at run time.
< 1561158723 507137 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :zzo38: Did you see the idea about function arguments that I wrote here yesterday?
< 1561158726 886763 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Do you like this?
< 1561158819 224021 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :I did not see it
< 1561159052 238476 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Ah. Well, tell me if you see it.
< 1561159069 66225 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I have some other ideas and questions that I didn't mention.
< 1561159968 925790 :arseniiv_!~arseniiv@136.169.202.147 QUIT :Ping timeout: 248 seconds
< 1561160073 966887 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :OK, I looked at it now.
< 1561160302 236382 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :You can pass structs in C and LLVM (and in LLVM, structs is just tuples anyways), but if interfacing with C codes, they will work differently. (You can deal with this in the declaration perhaps, though, and generate code to convert if needed)
< 1561160542 198273 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This is kind of a syntax/language semantics thing. The calling convention is ideally about the same.
< 1561160639 869972 :zzo38!~zzo38@24-207-15-213.eastlink.ca PRIVMSG #esoteric :Still if you use multiple outputs also as a multiple input then conversion must be performed (although it can be done automatically).