| 00:00:19 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 00:01:36 | * | mbenadda joined #nim |
| 00:02:27 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:04:33 | * | Trustable quit (Remote host closed the connection) |
| 00:04:57 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 00:04:59 | ldlework | reactormonk: I have no idea which issue you're referring to |
| 00:05:42 | * | mbenadda quit (Ping timeout: 244 seconds) |
| 00:08:17 | * | Nimbus joined #nim |
| 00:09:42 | * | boydgreenfield joined #nim |
| 00:09:49 | * | boydgreenfield quit (Client Quit) |
| 00:10:36 | * | Nimbus quit (Remote host closed the connection) |
| 00:13:12 | * | Nimbus joined #nim |
| 00:21:28 | * | repax quit (Quit: repax) |
| 00:26:09 | * | Nimbus quit (Remote host closed the connection) |
| 00:28:04 | * | Nimbus joined #nim |
| 00:28:37 | * | starless joined #nim |
| 00:29:45 | * | Nimbus quit (Remote host closed the connection) |
| 00:30:00 | * | Nimbus joined #nim |
| 00:30:38 | * | Nimbus quit (Remote host closed the connection) |
| 00:30:47 | * | Nimbus joined #nim |
| 00:30:58 | * | Varriount|Mobile joined #nim |
| 00:32:18 | * | Nimbus quit (Remote host closed the connection) |
| 00:32:27 | * | Nimbus joined #nim |
| 00:34:50 | Varriount|Mobile | Hi Nimbus |
| 00:35:30 | EXetoC | Nimbus: yo, bot! |
| 00:35:48 | flaviu | ,eval echo "hi Varrount" |
| 00:35:50 | Nimbus | flaviu: hi Varrount |
| 00:36:04 | flaviu | dts's bot |
| 00:36:31 | ldlework | it supports multiline? |
| 00:36:36 | flaviu | in a few moments |
| 00:36:57 | * | Nimbus quit (Remote host closed the connection) |
| 00:37:08 | * | Nimbus joined #nim |
| 00:38:10 | * | Nimbus quit (Remote host closed the connection) |
| 00:38:20 | * | Nimbus joined #nim |
| 00:39:15 | * | willwillson quit (Read error: Connection reset by peer) |
| 00:39:42 | * | Nimbus quit (Remote host closed the connection) |
| 00:39:52 | * | Nimbus joined #nim |
| 00:40:19 | * | Nimbus quit (Remote host closed the connection) |
| 00:40:28 | * | Nimbus joined #nim |
| 00:42:28 | * | Nimbus quit (Remote host closed the connection) |
| 00:42:37 | * | Nimbus joined #nim |
| 00:43:31 | * | Nimbus quit (Remote host closed the connection) |
| 00:43:40 | * | Nimbus joined #nim |
| 00:46:19 | * | Nimbus quit (Remote host closed the connection) |
| 00:46:28 | * | Nimbus joined #nim |
| 00:47:33 | * | Nimbus quit (Remote host closed the connection) |
| 00:47:42 | * | Nimbus joined #nim |
| 00:48:51 | * | Nimbus quit (Remote host closed the connection) |
| 00:48:59 | * | Nimbus joined #nim |
| 00:49:04 | * | Nimbus quit (Remote host closed the connection) |
| 00:49:28 | * | Nimbus joined #nim |
| 00:49:54 | * | Nimbus quit (Remote host closed the connection) |
| 00:50:03 | * | Nimbus joined #nim |
| 00:50:27 | * | sir_dts joined #nim |
| 00:53:47 | * | Nimbus quit (Remote host closed the connection) |
| 00:53:57 | * | Nimbus joined #nim |
| 00:54:01 | Varriount|Mobile | ? |
| 00:54:46 | flaviu | ldlework: ping |
| 00:54:49 | Varriount|Mobile | ,eval echo(2+3) |
| 00:54:50 | Nimbus | Varriount|Mobile: 5 |
| 00:55:03 | flaviu | it supports multiline |
| 00:55:03 | flaviu | ,eval import os ⏎echo("test" / "foo") |
| 00:55:05 | Nimbus | flaviu: test/foo |
| 00:55:17 | * | nimnoob quit (Ping timeout: 240 seconds) |
| 00:55:45 | ldlework | pong |
| 00:55:47 | ldlework | flaviu: |
| 00:55:50 | ldlework | oh |
| 00:55:51 | ldlework | cool |
| 00:56:22 | ldlework | flaviu: would you like to try the tech demo that will underlie my game? |
| 00:56:39 | Varriount|Mobile | flaviu: how does the bot detect newlines? |
| 00:57:16 | flaviu | Varriount|Mobile: Unicode! ⏎ |
| 00:57:20 | flaviu | ldlework: sure |
| 00:57:51 | Varriount|Mobile | flaviu: Huh? |
| 00:58:04 | flaviu | `⏎` means newline |
| 00:58:22 | EXetoC | how do I enter that on linux? |
| 00:58:30 | flaviu | copy paste :P |
| 00:58:30 | Varriount|Mobile | Nice, but I can't type that on my phone. |
| 00:59:18 | * | Nimbus quit (Remote host closed the connection) |
| 00:59:28 | * | Nimbus joined #nim |
| 00:59:35 | Varriount|Mobile | flaviu: what about an 'eval-start' and 'eval-end' commands? |
| 00:59:49 | flaviu | Dammit Varriount. Ok, just for you, 4c277a1773237fd5c8d333fedb4262238789c95b91bf2de7adc3db7175d374ad can also be used for newlines |
| 00:59:52 | * | rpag quit (Ping timeout: 245 seconds) |
| 00:59:59 | flaviu | I think that can be typed on phones |
| 01:00:16 | flaviu | ,eval echo "a"4c277a1773237fd5c8d333fedb4262238789c95b91bf2de7adc3db7175d374adecho "b" |
| 01:00:18 | Nimbus | flaviu: a |
| 01:00:21 | EXetoC | use something like «? |
| 01:00:37 | EXetoC | and then about 10 other common unicode characters |
| 01:00:43 | ldlework | flaviu: EXetoC https://github.com/dustinlacewell/nix |
| 01:00:50 | flaviu | ,eval echo("a" &4c277a1773237fd5c8d333fedb4262238789c95b91bf2de7adc3db7175d374ad "b") |
| 01:00:51 | Nimbus | flaviu: ab |
| 01:00:51 | ldlework | just nim c -r src/qix.nim |
| 01:01:13 | * | sir_dts quit (Ping timeout: 246 seconds) |
| 01:01:29 | flaviu | Varriount|Mobile: That's probably the best solution, I'll send it to dts|pokeball. |
| 01:01:43 | ldlework | flaviu: EXetoC to use it, hit shift and cut into the poly gon |
| 01:02:06 | ldlework | flaviu: EXetoC you should be able to make arbitrary cuts in any orientation from any edge or corner to any edge or corner, including the same one |
| 01:02:37 | flaviu | "undeclared identifier: 'drawStipple'" |
| 01:02:37 | flaviu | What are it's dependencies? |
| 01:02:42 | ldlework | oh |
| 01:02:53 | ldlework | I patched SDL_gfx to implement a stippled line |
| 01:02:54 | ldlework | lol |
| 01:03:19 | ldlework | I guess I should submit a PR for that... |
| 01:03:44 | flaviu | can you just gist the patch? |
| 01:03:53 | ldlework | flaviu: change line 164 in diamond.nim to use just drawLine |
| 01:03:55 | ldlework | or that |
| 01:03:57 | ldlework | sure |
| 01:04:22 | * | Var|Mobile joined #nim |
| 01:05:30 | ldlework | flaviu: https://gist.github.com/dustinlacewell/a3a66cc6da67c6894b96 |
| 01:05:34 | ldlework | it was a patch to graphics.nim |
| 01:05:38 | ldlework | not sdl_gfx |
| 01:06:42 | ldlework | I'm going to generalize it |
| 01:06:47 | ldlework | by adding a period parameter |
| 01:06:52 | ldlework | that defaults to 1 for solid line |
| 01:07:30 | EXetoC | no lines representing the output appears |
| 01:07:41 | flaviu | Yeah, I doesn't do anything for me either |
| 01:07:44 | * | Varriount|Mobile quit (Ping timeout: 245 seconds) |
| 01:08:02 | ldlework | what |
| 01:08:04 | EXetoC | there's only a red dot top-center |
| 01:08:08 | ldlework | hold shift |
| 01:08:09 | EXetoC | +in |
| 01:08:10 | ldlework | and press down |
| 01:08:13 | ldlework | into the square |
| 01:08:15 | Araq | not that I really care ... but how exactly is typing "ref T" everywhere not code monkey work? |
| 01:08:21 | flaviu | oh, arrow keys |
| 01:08:39 | ldlework | Araq: comapred to creating a superflous type for every type in your program? |
| 01:08:53 | EXetoC | there we go |
| 01:09:06 | Araq | and who thinks you need to do that? |
| 01:09:12 | Araq | Foo = ref object ... |
| 01:09:16 | Araq | Bar = object ... |
| 01:09:24 | Araq | there we go, no thinking involved |
| 01:09:36 | ldlework | for every single type |
| 01:09:55 | EXetoC | I don't the overhead is that big |
| 01:09:57 | ldlework | just so you can be less sure whether some name is a reference or value |
| 01:10:00 | Araq | read what I wrote |
| 01:10:04 | ldlework | Araq: I did |
| 01:10:33 | ldlework | Araq: what if you want a Foo on the stack? |
| 01:10:38 | ldlework | or a Bar on the heap |
| 01:10:52 | ldlework | What if I want to know at a glance what kind of types they are |
| 01:10:59 | flaviu | I'm not sure what I'm supposed to be doing, but I turned most the grid red. |
| 01:11:07 | ldlework | flaviu: that's all that you can do right now |
| 01:11:17 | ldlework | the point is that you can cut up that square anyway you want and it is stable |
| 01:11:23 | Araq | ldlework: then you move your mouse cursor over the type, dude |
| 01:11:31 | EXetoC | I told you about the convention, but it needs to be documented |
| 01:11:41 | ldlework | EXetoC: that convention is terrible |
| 01:11:59 | Araq | the convention IS documented |
| 01:12:05 | EXetoC | ok sorry |
| 01:12:09 | ldlework | Just because I'm looking at a Foo, it doesn't tell me whether there is some other FooObj, or some other FooRef |
| 01:12:15 | ldlework | It doesn't help - at all |
| 01:12:28 | Araq | so? we got rid of the ugly T/P |
| 01:12:38 | ldlework | Araq: he's talking about Ref and Obj postfixes |
| 01:12:48 | ldlework | in response to not knowing what whether a type is a ref or not |
| 01:12:57 | ldlework | The convention doesn't help that problem at all |
| 01:13:09 | Araq | yes, the new convention doesn't |
| 01:13:12 | * | Nimbus quit (Remote host closed the connection) |
| 01:13:14 | Araq | the old convention did |
| 01:13:24 | ldlework | I'll stick with ref, thanks |
| 01:13:44 | Araq | that's ridiculous too |
| 01:13:44 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 01:13:55 | Araq | ref Foo, ref Foo, ref Foo, ref Foo |
| 01:14:02 | ldlework | its one space |
| 01:14:03 | ldlework | OOOOOO |
| 01:14:16 | Araq | it basically a way of telling your readers they are idiots |
| 01:14:17 | ldlework | visually distinct and explicit |
| 01:14:27 | ldlework | Araq: do you think that argument would move me |
| 01:14:29 | ldlework | like |
| 01:14:33 | ldlework | do you think that's a strong objective argument |
| 01:14:34 | Araq | because they can't remember anything |
| 01:14:40 | ldlework | are you just being a dick at this point? |
| 01:14:41 | Araq | yes, it is |
| 01:14:44 | Araq | because |
| 01:14:47 | Araq | you |
| 01:14:53 | Araq | as every other programmer out there |
| 01:15:04 | Araq | totally ignores usage statistics |
| 01:15:09 | Araq | and stick to petty rules instead |
| 01:15:16 | ldlework | Sometimes I'm reading source code for the first time |
| 01:15:21 | Araq | which make sense when you never ever look at the result |
| 01:15:27 | ldlework | and type aliases because your ref keyword sucks -is a petty rule- |
| 01:15:44 | ldlework | Araq: you should go take a walk |
| 01:16:04 | flaviu | ldlework: How about everyone goes and takes a walk? |
| 01:16:56 | * | kmcguire quit (Ping timeout: 265 seconds) |
| 01:17:00 | flaviu | Both of you won't ever agree, so might as well drop it. |
| 01:18:00 | ldlework | Its fine to disagree |
| 01:18:17 | EXetoC | I did think about this before, but I can't say whether or not it's a problem that it's not obvious by looking at the code what the primary type is |
| 01:18:47 | ldlework | EXetoC: better be more implicit, since we're not sure |
| 01:18:48 | EXetoC | I know it won't be the end of the world, but I'll have to figure whether or not it'll bother me at all. |
| 01:18:59 | flaviu | Yes, but it's not fine for anyone to be rude in an argument, and this is religious war territory. |
| 01:30:05 | Araq | actually, it isn't. Either you stick to our style guidelines or you don't. Kind of ironic how everybody thinks style guidelines are important and yet nobody wants to follow them. |
| 01:31:27 | Araq | I personally think style guidelines are the most effective way to burn lots of money and not much more. |
| 01:39:10 | ldlework | Its a brand new language who's syntax is still changing here and there. Putting so much weight behind a style guide that has obviously had to fundamentally change due to T/P prefix removal is a bit vacous. |
| 01:39:32 | Araq | we discussed this topic for ages |
| 01:39:36 | ldlework | Consider me to be exploring whether type aliases are actually needed - at all |
| 01:39:54 | ldlework | Or whether they save a few keystrokes for less explicitness |
| 01:40:08 | Araq | and just fyi, C# doesn't distinguish between 'struct' and 'class' via type names either |
| 01:40:11 | ldlework | I'll let you know whether my users are insulted |
| 01:40:43 | Araq | well I'll tell you I'm insulted |
| 01:40:51 | Araq | but ofc I don't count |
| 01:41:01 | ldlework | But they do distinguish between value and reference types |
| 01:41:11 | ldlework | which is actually what is being discussed |
| 01:41:29 | Araq | C#'s DateTime -- struct or class? |
| 01:41:47 | ldlework | I know that it isn't a *REFERENCE TYPE8 |
| 01:42:02 | Araq | C# distinguishes it a bit differently from Nim, but the problem is exactly the same |
| 01:42:05 | * | starless quit (Quit: WeeChat 0.4.2) |
| 01:42:14 | ldlework | It isn't. |
| 01:42:19 | Araq | lol? |
| 01:42:29 | Araq | so where is the difference? |
| 01:42:40 | ldlework | The difference between a struct and and class isn't the same as whether you are dealing with a reference to either or not. |
| 01:44:01 | Araq | 'ref object' ~= class |
| 01:44:08 | Araq | 'object' ~= struct |
| 01:44:17 | ldlework | yeah, not at all |
| 01:44:27 | ldlework | I can take a ref to both in C# |
| 01:44:30 | ldlework | that's the issue we're dealing with |
| 01:44:38 | ldlework | I don't know why you're trying to conflate a completely unrelated issue |
| 01:44:54 | Araq | do you actually know C#? |
| 01:45:52 | ldlework | Yeah, and I'm fairly certain you can take a pointer to either a struct or a class. |
| 01:46:12 | ldlework | instance, that is |
| 01:46:27 | ldlework | int i = 5; |
| 01:46:29 | ldlework | int* j = &i; |
| 01:46:51 | ldlework | Do you? |
| 01:47:02 | Araq | I know it really well. |
| 01:47:17 | Araq | and I have no idea how you cannot agree with me |
| 01:47:38 | ldlework | uh because "ref object" ~= class and "object" ~= struct, is patently wrong? |
| 01:47:43 | ldlework | because C# has actual references to either? |
| 01:47:52 | ldlework | you're dodging reality and conflating unrelated issues? |
| 01:47:56 | ldlework | are those enough reasons? |
| 01:48:10 | Araq | these are reasons for sure, but they are all wrong. |
| 01:48:15 | ldlework | Demonstrate. |
| 01:48:20 | Araq | type Foo = ref object |
| 01:48:29 | Araq | same semantics (roughly) as: |
| 01:48:36 | Araq | class Foo { ... } |
| 01:48:43 | Araq | type Bar = object |
| 01:48:49 | Araq | --> struct Bar {...} |
| 01:48:55 | ldlework | So you've reiterated your conflated equivalency |
| 01:49:06 | ldlework | be surprised I'm not moved the second time either |
| 01:49:46 | ldlework | whether a name is a class or struct --is in no way in any possible interpretation-- the same problem of whether you have a pointer or a value |
| 01:50:14 | * | mbenadda joined #nim |
| 01:50:16 | ldlework | classes are not pointers, except perhaps from an internal implementation standpoint |
| 01:50:16 | Araq | it is EXACTLY the same problem |
| 01:50:19 | ldlework | Araq: okay |
| 01:50:21 | ldlework | so |
| 01:50:34 | ldlework | nevermind actually this is useless |
| 01:51:26 | ldlework | Araq: is i above a reference or a pointer? |
| 01:51:34 | ldlework | Araq: is j a reference or a pointer? |
| 01:51:42 | ldlework | How do you know the answer to either of those questions? |
| 01:51:53 | ldlework | HOW DOES THE ANSWER HAVE ANYTHING TO DO WITH WHETHER THE UNDERLYING TYPE IS A CLASS OR STRUCT |
| 01:51:58 | ldlework | ffs |
| 01:52:07 | ldlework | I call this "Arguing dishonestly" |
| 01:52:10 | ldlework | you're not lying |
| 01:52:15 | flaviu | ldlework: Relax, somehow you're being more rude than Araq. |
| 01:52:18 | ldlework | but you're completing ridiculously |
| 01:52:41 | ldlework | flaviu: really I haven't insulted his basic competence |
| 01:54:10 | Araq | well I don't know what to say. You think there are differences when there are none. |
| 01:54:24 | * | mbenadda quit (Ping timeout: 245 seconds) |
| 01:54:40 | ldlework | Araq: I've demonstrated that there are |
| 01:55:02 | Araq | 'int* j = &i;' is like: 'var j: ptr int = addr(i)' |
| 01:55:06 | ldlework | anyone who isn't in this wierd place where they feel stuck to defend a ridiculous untennable position can see the distinction |
| 01:55:33 | Araq | on the contrary everybody who knows a tiny bit of formal semantics knows that I'm right. |
| 01:55:47 | ldlework | why can't you answer my basic questions then? |
| 01:55:52 | ldlework | you didn't answer my question |
| 01:55:58 | ldlework | and simply provided another odd code metaphor |
| 01:56:15 | ldlework | how do you know i is a reference or value |
| 01:56:16 | Araq | I didn't notice there were any serious questions asked |
| 01:56:21 | ldlework | how do you know that j is a reference of value |
| 01:56:30 | ldlework | What informs you to those answers? |
| 01:56:46 | ldlework | and how is the thing that informs those answers, related to whether the underlying type is a class or struct? |
| 01:57:04 | ldlework | if the thing that informs you has nothing to do with whether the underlying type is a class or struct |
| 01:57:08 | ldlework | how do you justify your position? |
| 01:57:13 | ldlework | answer each question in order |
| 01:59:07 | Araq | j is a pointer because of the * |
| 01:59:27 | ldlework | so we know that j is a pointer because of something that has nothing at all to do with its underlying type |
| 01:59:33 | Araq | but again, DateTime could be a struct or a class |
| 01:59:43 | Araq | and it matters quite a bit |
| 01:59:46 | ldlework | so in C#, whether a name is a reference, or a value has nothing to do with whether its underlying type is a class or struct |
| 01:59:58 | ldlework | because in C#, references are not types |
| 02:00:03 | Araq | er no? classes are reference types |
| 02:00:09 | Araq | structs are value types |
| 02:00:20 | ldlework | from the underlying implementation standpoint you are correct |
| 02:00:32 | ldlework | but a user of the language cannot 'dereference' a class |
| 02:00:45 | ldlework | a user of the language doesn't care how to obtain the 'value' of a class instance by dereferencing it |
| 02:01:05 | ldlework | that a user has a value, an instance of a class, matters 0% for reference vs values semantics |
| 02:01:54 | ldlework | In C# the only thing that matters, that has anything to do with the issue in Nim about type names, is between values of struct AND classes, and POINTERS to those value types |
| 02:02:06 | Araq | so your point is that Nim still has this deref operation? |
| 02:02:23 | ldlework | Araq: no, that references are literally types in Nim |
| 02:02:26 | ldlework | and so it matters |
| 02:02:29 | ldlework | given any variable name |
| 02:02:38 | ldlework | whether the underlying type is implemented as a reference or value |
| 02:02:43 | ldlework | in the sense of pointer or value |
| 02:02:57 | ldlework | not in the sense of "Oh C# classes are implemented underneat as references." |
| 02:03:02 | Araq | it matters in C# too. = either copies, or it doesn't. |
| 02:03:08 | ldlework | right |
| 02:03:10 | ldlework | but in C# |
| 02:03:17 | ldlework | you don't go to the underlying type of the value |
| 02:03:22 | ldlework | you either have a reference or a value |
| 02:03:30 | Araq | yes well |
| 02:03:35 | ldlework | in C# you don't look to see whether int is a reference or value type |
| 02:03:40 | Araq | that is actually what the guidelines propose |
| 02:03:41 | ldlework | the name of the type is irrelevant in C# |
| 02:03:52 | ldlework | in C# * and & tell you |
| 02:03:52 | Araq | and what dom96 tried to explain to you. |
| 02:03:54 | ldlework | just like |
| 02:03:56 | ldlework | in nim |
| 02:03:58 | ldlework | how ref tells you |
| 02:04:03 | ldlework | as long as you only define value types |
| 02:04:05 | ldlework | TADA |
| 02:04:07 | ldlework | exactly my style |
| 02:04:19 | * | ldlework goes home |
| 02:05:03 | Araq | it still makes no sense tbh |
| 02:05:51 | Araq | 'ref' is not used like *, 'ref object' is used like 'class' |
| 02:05:55 | ldlework | no |
| 02:06:02 | ldlework | ref is used like & |
| 02:06:08 | ldlework | I know its true |
| 02:06:15 | ldlework | because I write Nim code under this assumption |
| 02:06:18 | ldlework | and surprise surprise |
| 02:06:21 | ldlework | my programs compile |
| 02:06:33 | Araq | & is addr |
| 02:06:44 | ldlework | holy shit |
| 02:06:46 | Araq | C++'s & is Nim's 'var' |
| 02:06:59 | ldlework | Araq: you don't actually care to understand |
| 02:07:01 | ldlework | just reiterate |
| 02:07:02 | Araq | C#'s * is Nim's 'ptr' |
| 02:07:38 | ldlework | Araq: I don't use ptr's in Nim |
| 02:07:38 | Araq | how can you say "ref is used like &" when one is a type constructor and the other an operator? |
| 02:07:48 | ldlework | so for me, there are only values and refs |
| 02:07:53 | ldlework | in which case |
| 02:08:02 | ldlework | ref acts exactly like the "get a reference to this value" operator in C# |
| 02:08:13 | Araq | no |
| 02:08:17 | Araq | not at all. |
| 02:08:27 | ldlework | I must just be incredibly lucky with the compiler then |
| 02:08:37 | ldlework | Or your making a point that has no bearing on the actual writing of code |
| 02:08:46 | Araq | listen |
| 02:08:57 | Araq | &i is a *value* |
| 02:09:04 | Araq | 'ref int' is a *type* |
| 02:09:13 | ldlework | I understand that dude |
| 02:09:14 | flaviu | ldlework: I'm Araq isn't deliberately failing to understand as I don't understand what you're saying either. Can you post code doing what you describe? |
| 02:09:22 | ldlework | I've already mentioned that in Nim references are types |
| 02:09:26 | ldlework | that I understand this distinction |
| 02:09:42 | ldlework | flaviu: its easy |
| 02:09:49 | ldlework | I define ALL my types as non-ref types |
| 02:09:53 | ldlework | then when I want a reference |
| 02:09:57 | ldlework | I use "ref T" |
| 02:10:01 | ldlework | it isn't that hard to understand |
| 02:10:16 | Araq | yes, that part is perfectly clear |
| 02:10:17 | ldlework | just like in C# when you want to store a reference, you do int* |
| 02:10:27 | ldlework | the type is defined as a reference |
| 02:10:35 | ldlework | it just so happens that we don't need & in Nim |
| 02:10:38 | Araq | but you cannot get this 'ref' from T at all. you have to 'new' it. |
| 02:10:57 | ldlework | that's correct, ref is not actually an operator in Nim |
| 02:12:01 | ldlework | I don't use ref to get references to things on the stack |
| 02:12:09 | Araq | ok, I need to sleep but: |
| 02:12:09 | * | brson quit (Ping timeout: 272 seconds) |
| 02:12:10 | ldlework | I use ref to explicitly mark that I'm working with reference types |
| 02:12:13 | * | z1y joined #nim |
| 02:12:26 | Araq | 1. I know what you do. |
| 02:12:54 | Araq | 2. The style guide suggests to treat 'ref object' and 'object' like 'class' and 'struct' in C#. |
| 02:15:15 | Araq | 3. It is dishonest to complain about the problem that you cannot tell 'ref object' from 'object' and *at the same time* that C# doesn't have the same problem. |
| 02:15:32 | Araq | Good night. |
| 02:16:33 | ldlework | I know when I'm creating a reference or a value in C# because of * and &, and I know need to look at the definition of the type - ever in any context in C# |
| 02:16:48 | ldlework | and I don't need* |
| 02:17:38 | ldlework | In Nim, you have the problem in that var f = newFoo(), may result in a refrence or value |
| 02:19:16 | flaviu | ldlework: Is there something you can do with a reference that you can't with a value or the other way around? |
| 02:19:19 | * | z1y left #nim (#nim) |
| 02:19:53 | flaviu | ref T and var T are pretty much the same thing. |
| 02:20:10 | * | brson joined #nim |
| 02:20:55 | * | kniteli quit (Ping timeout: 250 seconds) |
| 02:22:12 | j3rky | i don't mean to interrupt the argument, but it looks like Araq went to sleep now. would someone be willing to help an idiot? i can't get Aporia to build. i'm on a fresh ArchLinux install, built nim from GitHub, followed the readme and installed all dependencies, but "glib2 cannot be opened" in aporia.nim. maybe my PATH is not set up right? |
| 02:23:14 | flaviu | j3rky: You have nothing to apologize about. Just to make sure, you have glib2 installed? |
| 02:23:27 | j3rky | yep, pacman says it's installed |
| 02:23:31 | * | kniteli joined #nim |
| 02:23:42 | ldlework | flaviu, .... |
| 02:25:29 | flaviu | j3rky: I can reproduce it, give me a few moments to figure it out. |
| 02:25:40 | j3rky | ok thanks |
| 02:26:53 | ldlework | flaviu: passing a ref or var to an impure function is pretty important distinction |
| 02:27:28 | EXetoC | ldlework: you don't know about the newFoo/initFoo distinction then |
| 02:27:28 | ldlework | if I pass some vars around to an impure function that modifies fields in order to do some calculations, then those functions don't mutate the data |
| 02:27:51 | ldlework | EXetoC: so now how I have to define multiple constructors to avoid the ref keyword too?! |
| 02:28:45 | EXetoC | ldlework: few people have actually needed to define both |
| 02:28:58 | EXetoC | but there are planned features that are relevant to this |
| 02:29:09 | ldlework | I like when I delve into some code, and I see ref anywhere I know the consequences of impure functions |
| 02:29:11 | ldlework | Is that ok? |
| 02:29:19 | EXetoC | which I've brought up once or twice today already |
| 02:29:58 | ldlework | ref aliases give nothing of value |
| 02:30:06 | ldlework | Its like asking "Why don't you believe in God? |
| 02:30:13 | ldlework | There is literally *no* reason to do so. |
| 02:30:41 | ldlework | Nothing motivates it. Except that we've arbitrarily decided that it is a good idea. |
| 02:31:06 | ldlework | And henceforth planned features, extra functions and so on to work around the consequences of that decision. |
| 02:31:07 | flaviu | ldlework: You should keep religion out of this, it won't lead anywhere productive. |
| 02:31:13 | ldlework | I'll just use 'ref'. |
| 02:31:25 | EXetoC | that's not what you were talking about just then though, and neither was I |
| 02:31:41 | flaviu | j3rky: Well, running `nimble install gtk2` seems to postpone the error a bit |
| 02:32:00 | ldlework | I mean |
| 02:32:04 | ldlework | why not remove the ref keyword |
| 02:32:09 | ldlework | and replace 'ref object' |
| 02:32:11 | ldlework | with 'reference' |
| 02:32:23 | ldlework | if it is not used anywhere else |
| 02:37:41 | EXetoC | if you're referring to the conventions, then you might still have situations where the ref type is not the primary one, so you need to do "FooRef = ref Foo" |
| 02:38:24 | EXetoC | and it's difficult to remove a keyword just like that, though we still are at <1.0, but it needs to justified either way |
| 02:39:42 | j3rky | flaviu: postpone as in it will still break later, or as in it will build Aporia successfully? :) |
| 02:39:53 | flaviu | j3rky: I'm not sure, perhaps you could message dom96 tomorrow. `s/(func/(funcc/` and `s/ func/ funcc/` for `~/.nimble/pkgs/gtk2-1.0/gtk2.nim` fixes most problems, but I then get a weird error message that I don't understand |
| 02:40:03 | flaviu | It will fail to build, but later in the process. |
| 02:40:12 | j3rky | i see |
| 02:40:31 | j3rky | ok, i will message dom96 tomorrow. thank you so much for looking into it! |
| 02:40:45 | flaviu | No problem, happy to help. |
| 02:41:00 | j3rky | what other IDEs / text editors do people here use for programming in nim? |
| 02:41:54 | j3rky | from what i understand, only Aporia offers auto completion to some extent right now, is that correct? |
| 02:42:39 | * | brson_ joined #nim |
| 02:42:46 | * | brson_ quit (Client Quit) |
| 02:43:04 | * | brson quit (Read error: Connection reset by peer) |
| 02:43:10 | * | brson joined #nim |
| 02:43:41 | flaviu | Yes, although other text editors do offer dumb auto completion. Sublime text is good. |
| 02:47:23 | * | brson quit (Client Quit) |
| 02:47:39 | * | brson joined #nim |
| 02:52:35 | * | darkf joined #nim |
| 02:54:28 | * | z1y joined #nim |
| 02:56:32 | * | flaviu quit (Ping timeout: 250 seconds) |
| 02:57:38 | * | Jesin joined #nim |
| 03:02:31 | * | brson quit (Ping timeout: 250 seconds) |
| 03:03:26 | * | darkf quit (Ping timeout: 258 seconds) |
| 03:09:10 | fowl | func keyword is probably used in every wrapper |
| 03:10:00 | fowl | it was in a lot of mine |
| 03:12:34 | * | nimnoob joined #nim |
| 03:15:13 | * | darkf joined #nim |
| 03:15:13 | * | darkf quit (Changing host) |
| 03:15:14 | * | darkf joined #nim |
| 03:15:44 | * | nimnoob quit (Remote host closed the connection) |
| 03:19:25 | Varriount_ | Araq: Um, I think you need to update github's commit hook, so the buildbots know when to build |
| 03:24:28 | EXetoC | so does anyone know of any capable C parsers? otherwise I'll just see if pycparser is anything to write home about |
| 03:25:10 | Varriount_ | EXetoC: What kind of parser are you talking about? |
| 03:25:19 | Varriount_ | Oh, wait, C parsers. |
| 03:25:31 | Varriount_ | I thought you had meant parsers written in C. |
| 03:25:57 | fowl | EXetoC, something from clang probably |
| 03:26:00 | Varriount_ | EXetoC: Well, wouldn't Clang and GCC have C parsers? |
| 03:26:09 | * | Varriount_ is now known as Varriount |
| 03:28:26 | EXetoC | right.. |
| 03:33:18 | * | nimnoob joined #nim |
| 03:39:02 | * | mbenadda joined #nim |
| 03:43:20 | * | mbenadda quit (Ping timeout: 250 seconds) |
| 03:58:01 | * | dain_ quit (Quit: dain_) |
| 04:02:38 | * | brson joined #nim |
| 04:09:17 | * | kapil__ joined #nim |
| 04:19:27 | * | z1y quit (Ping timeout: 272 seconds) |
| 04:22:49 | * | z1y joined #nim |
| 04:27:48 | * | nimnoob_ joined #nim |
| 04:27:48 | * | nimnoob quit (Read error: Connection reset by peer) |
| 04:28:07 | * | nimnoob_ quit (Client Quit) |
| 04:28:54 | * | nimnoob joined #nim |
| 04:59:06 | * | nimnoob quit (Quit: Leaving) |
| 05:00:49 | * | gmpreussner joined #nim |
| 05:01:30 | * | j3rky quit (Ping timeout: 258 seconds) |
| 05:27:46 | * | mbenadda joined #nim |
| 05:32:14 | * | mbenadda quit (Ping timeout: 244 seconds) |
| 05:39:46 | * | kniteli quit (Read error: Connection reset by peer) |
| 05:41:38 | * | ARCADIVS joined #nim |
| 05:56:59 | * | kniteli joined #nim |
| 06:03:45 | * | Jesin quit (Quit: Leaving) |
| 06:15:04 | gmpreussner | if i declare a type with "type Foo = distinct array[0..123]", how can i "borrow" the [] notation, so that i can still access array elements, i.e "myFooValue[42]"? |
| 06:26:57 | * | z1y quit (Remote host closed the connection) |
| 06:28:03 | * | z1y joined #nim |
| 06:29:07 | * | gmpreussner is now known as j3rky|zzZzz |
| 06:34:55 | * | yglukhov_ quit (Quit: Be back later ...) |
| 06:35:30 | * | dyu joined #nim |
| 06:41:28 | * | yglukhov_ joined #nim |
| 06:42:59 | * | yglukhov__ joined #nim |
| 06:42:59 | * | yglukhov_ quit (Read error: Connection reset by peer) |
| 06:47:32 | * | yglukhov__ quit (Ping timeout: 265 seconds) |
| 06:56:35 | * | yglukhov__ joined #nim |
| 06:56:43 | * | j3rky|zzZzz quit (Ping timeout: 265 seconds) |
| 06:59:19 | * | yglukhov__ quit (Read error: Connection reset by peer) |
| 06:59:48 | * | yglukhov__ joined #nim |
| 07:00:19 | * | brson quit (Ping timeout: 272 seconds) |
| 07:04:24 | * | yglukhov__ quit (Ping timeout: 250 seconds) |
| 07:08:14 | * | gour joined #nim |
| 07:08:32 | * | perturbation joined #nim |
| 07:09:54 | * | gour quit (Client Quit) |
| 07:11:28 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 07:14:48 | dts|pokeball | back |
| 07:15:04 | dts|pokeball | yeah Varriount i was thinking of doing something like that |
| 07:16:02 | * | gour joined #nim |
| 07:16:33 | * | mbenadda joined #nim |
| 07:20:44 | * | mbenadda quit (Ping timeout: 244 seconds) |
| 07:31:00 | * | boydgreenfield joined #nim |
| 07:33:48 | * | perturbation quit (Quit: Leaving) |
| 07:41:33 | * | kapil__ joined #nim |
| 07:50:07 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 08:12:56 | * | BlaXpirit joined #nim |
| 08:13:56 | * | BlaXpirit quit (Client Quit) |
| 08:17:16 | * | mbenadda joined #nim |
| 08:19:11 | * | yglukhov__ joined #nim |
| 08:21:47 | * | mbenadda quit (Ping timeout: 265 seconds) |
| 08:42:59 | * | mbenadda joined #nim |
| 08:45:48 | * | khmm joined #nim |
| 08:48:58 | z1y | do we have any book on #nim? or any .pdf resource? I'd like to print and read on papers... |
| 08:52:38 | z1y | curl -Lo- http://nim-lang.org/gc.html | sed -e 's#It it not #It is not#' |
| 09:04:10 | * | khmm quit (Ping timeout: 255 seconds) |
| 09:08:50 | * | khmm joined #nim |
| 09:16:40 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 09:25:24 | * | Trustable joined #nim |
| 10:17:26 | * | kniteli quit (Ping timeout: 244 seconds) |
| 10:25:59 | Araq | z1y: you can generate a PDF from the manual |
| 10:26:14 | Araq | let me push some patch so that "koch pdf" works |
| 10:26:53 | z1y | Thanks Araq. I will try |
| 11:03:13 | * | khmm quit (Ping timeout: 265 seconds) |
| 11:04:22 | * | khmm joined #nim |
| 11:15:47 | * | z1y quit (Ping timeout: 265 seconds) |
| 11:28:11 | * | repax joined #nim |
| 11:41:04 | dyu | Araq: I tried to run the lib tests via koch test c lib... then I modify it and add something in whenIsMainModule, it doesn't get picked up on next run? |
| 11:41:56 | * | Jesin joined #nim |
| 11:42:05 | dyu | I had a patch on strutils I wanted to test before doing a PR |
| 11:42:36 | * | flaviu joined #nim |
| 11:55:05 | * | flaviu quit (Ping timeout: 244 seconds) |
| 11:56:30 | Araq | dyu: hrm well 'lib' is special |
| 11:56:50 | Araq | maybe run 'stdlib' instead |
| 12:00:17 | dyu | Araq: ok, so I'll move the tests to tstrutil.nim ... is there a shortcut to running one test file? |
| 12:00:36 | Araq | nim c -r tests/foo/tfoo.nim |
| 12:01:25 | dyu | ok |
| 12:01:26 | dyu | thanks |
| 12:01:42 | Araq | maybe the tester also supports that |
| 12:01:48 | Araq | but I never run a single test |
| 12:02:05 | Araq | I run full categories. always. |
| 12:02:14 | dyu | takes a while |
| 12:02:34 | * | dyu not using ssd |
| 12:02:45 | Araq | well that depends on the category |
| 12:03:01 | * | kmcguire joined #nim |
| 12:03:03 | Araq | dom96: I will also write a forum entry about this but |
| 12:03:12 | Araq | I found your future.nim tests |
| 12:03:17 | Araq | and noticed something |
| 12:03:24 | * | xcombelle joined #nim |
| 12:04:04 | Araq | noReturn(() -> void => echo("noReturn")) |
| 12:04:09 | Araq | Now needs to be: |
| 12:04:16 | Araq | noReturn((() -> void) => echo("noReturn")) |
| 12:04:28 | dom96 | where are the tests? |
| 12:04:30 | Araq | because I made arraw like operators right associative |
| 12:04:40 | Araq | closures/tclosuremacro.nim |
| 12:04:49 | Araq | I moved it to 'macros' btw |
| 12:05:03 | Araq | as it tests macros moreso than closures |
| 12:05:17 | dom96 | ok |
| 12:05:36 | Araq | btw I also fixed your macro :P |
| 12:05:54 | Araq | but the question is: should arrows really be right assoc? |
| 12:06:10 | Araq | it's the right thing to do for int->int->int |
| 12:06:21 | Araq | but not for a->b => a+b |
| 12:06:56 | * | EXetoC quit (Read error: No route to host) |
| 12:07:30 | * | EXetoC joined #nim |
| 12:12:53 | dyu | Araq: did the PR ... btw, the files in tests/stdlib seems to have a different line separator than in lib/pure |
| 12:13:27 | dyu | I had to use vi to edit tstrutils.nim, to not mess up the diff |
| 12:13:42 | Araq | poor lad |
| 12:13:52 | dyu | hehe |
| 12:14:00 | dyu | why is it different though |
| 12:14:13 | Araq | because I use tools which don't give a fuck |
| 12:14:33 | Araq | tools that came after the invention of sliced bread |
| 12:15:46 | dyu | Araq: you open to reformatting test/* with same formatting as lib/*? |
| 12:16:02 | * | jasondotstar is now known as jasondotstar|afk |
| 12:17:31 | * | BlaXpirit joined #nim |
| 12:17:38 | Araq | it it means I also get useful PRs from you. |
| 12:17:42 | Araq | *IF |
| 12:18:01 | dyu | well its for consistency first and foremost |
| 12:18:03 | dyu | :P |
| 12:20:13 | Araq | consistency with 1960? |
| 12:21:45 | * | dyu doesn't get it |
| 12:23:05 | Araq | I don't want to discuss this again |
| 12:28:50 | EXetoC | dyu: your editor converts all the newlines? otherwise I don't know what the problem is |
| 12:29:32 | dyu | EXetoC: yep (gedit) |
| 12:30:08 | dyu | theres probably a switch to turn in off |
| 12:30:56 | Araq | use aporia instead. it's like gedit. but with an acceptable search&replace. |
| 12:31:25 | dyu | I used aporia before, doesn't compile anymore on my ubuntu laptop |
| 12:32:05 | Araq | fix it please |
| 12:35:43 | dom96 | Araq: Using -> and => shouldn't be necessary often, especially if you improve type inference. |
| 12:36:13 | Araq | dom96: well I fixed 'auto'. I think. |
| 12:36:19 | Araq | need to test that again |
| 12:36:41 | Araq | otherwise type inference is as good as it'll get, I'm afraid |
| 12:39:02 | * | noam joined #nim |
| 12:40:20 | EXetoC | dom96: why not? aren't they shortcuts? |
| 12:45:56 | * | clone1018_ joined #nim |
| 12:46:28 | * | Triplefox quit (Ping timeout: 255 seconds) |
| 12:46:54 | Araq | EXetoC: he means using both at the same time as in the example I gave |
| 12:47:35 | * | Triplefox joined #nim |
| 12:52:34 | Araq | dyu: thanks for your PR but as usual, I can see the trouble |
| 12:52:56 | Araq | 1. Is the 'r' prefix what we want for 'reversed'? |
| 12:53:46 | Araq | 2. It's only a version for 'char'. Will annoy people too. |
| 13:03:03 | EXetoC | I think 'r' will be obvious to many |
| 13:05:00 | Araq | what does Ruby use for this? |
| 13:05:21 | Araq | everything else is obviously wrong anyway |
| 13:05:59 | yglukhov__ | The char version of rfind is actually consistent with existing string version =) |
| 13:09:10 | dyu | yglukhov__: right on |
| 13:09:18 | Araq | ah Ruby uses the 'r' prefix too. so it's all good. Now I want to sleep with it, it's so sexy. |
| 13:10:21 | EXetoC | >.> |
| 13:10:22 | dyu | Araq: didn't you write rfind for the string arg? |
| 13:11:12 | Araq | no? does that exist already? o.O |
| 13:11:21 | dyu | yep |
| 13:11:27 | dyu | I simply ran with it |
| 13:11:35 | Araq | oh ok lol. |
| 13:15:16 | Araq | guys, who will make the PR for this: https://github.com/Araq/Nimrod/issues/1747 |
| 13:15:55 | Araq | improving the CSS is acceptable, rewriting it in Ruby-DSL-for-fixing-CSS-of-the-week is not. |
| 13:20:31 | EXetoC | Araq: I don't know which example you gave, but in what ways won't inference be improved? I recall having to annotate at least the return type for lambdas |
| 13:21:03 | EXetoC | not having to would be nice of course, but the lambda syntax on its own is already a nice shortcut |
| 13:21:45 | EXetoC | oooo, live comment updates on github. hi-tech |
| 13:26:39 | * | xcombelle quit (Ping timeout: 272 seconds) |
| 13:30:47 | dom96 | Araq: I'm assuming you don't actually want that yellow background? |
| 13:33:36 | Araq | well I do. but i can imagine nobody else. |
| 13:35:40 | dom96 | Yeah... Please no. |
| 13:41:28 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 13:43:14 | Araq | ping Varriount |
| 13:46:13 | EXetoC | I think the background transition looks odd in any case, but not many people seem to have much negative to say about the overall design |
| 13:56:32 | * | kapil__ joined #nim |
| 13:59:19 | * | nickles joined #nim |
| 14:07:01 | * | BitPuffin joined #nim |
| 14:07:17 | nickles | Where did nimbuild go? |
| 14:15:31 | Araq | it's disabled because I switched servers |
| 14:15:40 | Araq | and maybe will be revived |
| 14:24:39 | nickles | thx |
| 14:27:19 | * | nickles left #nim (#nim) |
| 14:29:46 | * | willwillson joined #nim |
| 14:31:25 | willwillson | EXetoC: would libclang suffice for your c parsing needs? https://github.com/cowboy-coders/nim-libclang |
| 14:34:18 | Araq | EXetoC: either use clang or c2nim ;-) |
| 14:41:57 | EXetoC | willwillson: great |
| 14:47:46 | EXetoC | Araq: people want more automatic tools obviously, so I thought I'd look into using a full-fledged parser |
| 14:47:52 | EXetoC | but c2nim does an alright job as you say |
| 14:48:11 | EXetoC | and now I have about 101 things in the pipeline |
| 14:48:26 | Araq | well a full-fledged parser also has its disadvantages |
| 14:55:57 | EXetoC | ok |
| 14:57:16 | * | xcombelle joined #nim |
| 15:16:22 | * | jasondotstar|afk quit (Ping timeout: 256 seconds) |
| 15:24:29 | * | jasondotstar|afk joined #nim |
| 15:37:31 | * | darkf quit (Quit: Leaving) |
| 15:41:23 | * | jasondotstar|afk quit (Ping timeout: 244 seconds) |
| 15:57:35 | * | z1y joined #nim |
| 16:00:39 | * | jasondotstar joined #nim |
| 16:01:28 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 16:01:32 | * | xcombelle quit (Ping timeout: 244 seconds) |
| 16:27:13 | * | askatasuna joined #nim |
| 16:28:22 | * | saml_ joined #nim |
| 16:34:41 | * | khmm quit (Ping timeout: 264 seconds) |
| 16:37:47 | * | z1y quit (Ping timeout: 245 seconds) |
| 16:47:35 | * | kmcguire quit (Ping timeout: 250 seconds) |
| 16:48:11 | * | Matthias247 joined #nim |
| 16:49:41 | * | kmcguire joined #nim |
| 16:50:42 | * | askatasuna quit (Ping timeout: 250 seconds) |
| 16:53:29 | * | willwillson quit (Remote host closed the connection) |
| 16:55:57 | * | BlaXpirit-UA joined #nim |
| 16:58:37 | * | BlaXpirit quit (Ping timeout: 245 seconds) |
| 17:04:03 | * | shevy joined #nim |
| 17:04:09 | shevy | you finally did it! |
| 17:04:20 | shevy | long live nim |
| 17:04:22 | shevy | down with nimrod! |
| 17:12:53 | * | Trustable quit (Remote host closed the connection) |
| 17:24:47 | * | StefanSalewski joined #nim |
| 17:26:27 | StefanSalewski | Remark: Seems when we click on online-irc from bottom of main page, we get invalid #nim-lang channel. Valid #nim channel is only from Forum page? |
| 17:27:32 | StefanSalewski | Question: what does "type time_t* {.importc: "time_t", header: "<sys/time.h>".} = int" as used in wrappers of cowboy coder? |
| 17:28:02 | * | Sembei quit (Read error: Connection reset by peer) |
| 17:28:03 | * | gour quit (Disconnected by services) |
| 17:28:04 | * | gour___ joined #nim |
| 17:28:19 | * | gour___ is now known as gour |
| 17:29:57 | * | Sembei joined #nim |
| 17:30:34 | ldlework | StefanSalewski: its really easy to make pull requests for fixes like that |
| 17:30:37 | ldlework | the website thing |
| 17:31:11 | ldlework | StefanSalewski: it defines an import from a c library |
| 17:31:21 | * | repax quit (Ping timeout: 250 seconds) |
| 17:32:03 | ldlework | here it is importing a type, "time_t" as "time_t" as defined in "sys/time.h" which returns an int |
| 17:32:19 | ldlework | I think |
| 17:32:21 | ldlework | :) |
| 17:35:26 | StefanSalewski | Idleworks, import from c lib is clear, import type time_t also. The " = int" is where I have no idea. May be a fallback? |
| 17:35:50 | ldlework | StefanSalewski: I imagine it means like, "this type has the same size as an int" |
| 17:37:23 | EXetoC | it's just like any other type definition, so you can make it an object if you want |
| 17:38:56 | EXetoC | if the C type is not opaque obviously. the binary layout needs to match in any case |
| 17:39:39 | EXetoC | grep for "importc.*object" in the compiler dir if you want to see more examples |
| 17:40:34 | * | fowlmouth joined #nim |
| 17:40:56 | EXetoC | but the plan is to minimize the occurrences so as to be more target-agnostic |
| 17:40:58 | * | askatasuna joined #nim |
| 17:41:43 | * | StefanSalewski quit (Quit: Page closed) |
| 17:43:37 | * | fowl quit (Ping timeout: 240 seconds) |
| 17:46:39 | * | StefanSalewski joined #nim |
| 17:48:18 | * | xcombelle joined #nim |
| 17:53:52 | * | StefanSalewski quit () |
| 17:58:26 | * | yglukhov__ quit (Ping timeout: 256 seconds) |
| 17:59:11 | * | flaviu joined #nim |
| 18:03:43 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 18:13:44 | flaviu | Araq: Calling sass "Ruby-DSL-for-fixing-CSS-of-the-week" is unfair. It's been around two years longer than nim has. |
| 18:15:23 | * | vendethiel joined #nim |
| 18:29:45 | * | askatasuna quit (Quit: WeeChat 1.0.1) |
| 18:32:03 | * | mbenadda quit (Quit: Be back later ...) |
| 18:32:25 | * | kniteli joined #nim |
| 18:32:29 | * | mbenadda joined #nim |
| 18:35:23 | EXetoC | it does seem to be a well-established tool, and it does serve a purpose |
| 18:40:27 | * | yglukhov__ joined #nim |
| 18:44:18 | ldlework | can someone review https://github.com/Araq/Nimrod/pull/1753 |
| 18:44:22 | ldlework | (its trivial) |
| 18:47:38 | EXetoC | I would just add an empty line after each block, that's all |
| 18:48:10 | ldlework | What do you mean? |
| 18:48:15 | ldlework | I didn't change any of the formatting |
| 18:53:43 | EXetoC | it's consistent apparently |
| 18:54:13 | * | skyfex joined #nim |
| 18:54:15 | * | zio_tom78 joined #nim |
| 18:55:56 | zio_tom78 | Guys, I've read the IRC logs of the last two days |
| 18:56:24 | zio_tom78 | I suggest you to do the same |
| 18:56:44 | ldlework | We've been here, why would we need to read them |
| 18:57:14 | zio_tom78 | Re-read them, I assure you it's useful |
| 18:57:42 | * | Matthias247_ joined #nim |
| 18:58:01 | ldlework | yeah maybe you could just make your point |
| 18:58:24 | zio_tom78 | A overall change of tone might help when discussing things in a public forum |
| 18:58:43 | EXetoC | sure |
| 18:59:16 | skyfex | I'm getting an error when trying to run nimble |
| 18:59:42 | skyfex | http://pastebin.com/EC4UqPWa |
| 18:59:53 | skyfex | Is this a known issue? |
| 19:00:05 | EXetoC | that's all? |
| 19:00:16 | skyfex | (Missed a line: SIGSEGV: Illegal storage access. (Attempt to read from nil?)) |
| 19:00:17 | * | Matthias247 quit (Ping timeout: 240 seconds) |
| 19:00:22 | * | rpag joined #nim |
| 19:00:44 | skyfex | json.nim is tryng to read from a nil cstring |
| 19:00:51 | skyfex | haven't found out why yet |
| 19:00:53 | zio_tom78 | When a few days ago somebody complained about being mistreated on #rust, one of the core developers immediately answered and promised immediate action |
| 19:01:14 | ldlework | zio_tom78: who do you feel was mistreated |
| 19:01:20 | * | BitPuffin quit (Ping timeout: 256 seconds) |
| 19:01:36 | EXetoC | skyfex: is the latest issue relevant? |
| 19:02:00 | EXetoC | did you browse the issue list? |
| 19:02:08 | skyfex | Yes, same issue |
| 19:02:09 | skyfex | Duh |
| 19:02:29 | skyfex | (sorry) |
| 19:03:26 | zio_tom78 | I am not saying the same applies here, I'm saying that #nim should care about its participants as #rust does |
| 19:04:12 | zio_tom78 | Apparently in #rust there are people that check that conversations evolve in the most respectful way for everybody |
| 19:04:16 | ldlework | zio_tom78: if anything, the last days have been being an cactus to Araq |
| 19:04:24 | ldlework | been me being* |
| 19:04:32 | shevy | a cactus? |
| 19:04:41 | ldlework | a pain in the ass |
| 19:04:48 | shevy | lol |
| 19:04:57 | zio_tom78 | Idlework: I agree |
| 19:05:01 | shevy | how you can associate that with a cute small cactus plant! |
| 19:05:15 | EXetoC | such cuddly |
| 19:05:37 | shevy | people even jump into larger cactuses, like in the jackass movie! |
| 19:06:13 | EXetoC | (>_<) |
| 19:08:04 | * | zio_tom78 quit (Quit: Bye) |
| 19:08:33 | * | enurlyx joined #nim |
| 19:08:39 | * | Trixar_za quit (Ping timeout: 244 seconds) |
| 19:08:40 | * | Trixar_za joined #nim |
| 19:08:49 | * | yglukhov__ quit (Quit: Be back later ...) |
| 19:12:41 | * | nimnoob joined #nim |
| 19:17:22 | * | yglukhov__ joined #nim |
| 19:37:42 | * | irrequietus joined #nim |
| 19:49:40 | * | xcombelle quit (Ping timeout: 250 seconds) |
| 20:01:14 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
| 20:01:33 | * | BlaXpirit joined #nim |
| 20:01:34 | * | EXetoC1 joined #nim |
| 20:04:17 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 20:20:10 | ldlework | Araq mind merging, https://github.com/Araq/Nimrod/pull/1753 |
| 20:30:44 | Araq | hi ldlework. I'm not sure this shouldn't be a new proc instead. |
| 20:31:06 | ldlework | Araq: I figured that since it does not affect the API it was fine |
| 20:31:15 | ldlework | Also, do we introduce stipple versions of every drawing func? |
| 20:31:28 | ldlework | that seems like bloat for something that default args handles well |
| 20:32:31 | ldlework | let me know what you want |
| 20:32:39 | Araq | well I'm not sure |
| 20:32:48 | Araq | is stippling all that common? |
| 20:33:15 | ldlework | Its certainly inconvenient for someone who wants a stippled version of a circle, for example, to have to fork the existing drawing routine in their own code. |
| 20:33:35 | * | brson joined #nim |
| 20:33:56 | ldlework | Which is what I will have to do if you don't like supporing a stipple option |
| 20:35:14 | Araq | well I can say the same for transparency |
| 20:35:32 | Araq | so thing is, we need to expose the *algorithm* in form of templates instead |
| 20:35:57 | ldlework | Araq: that's interesting |
| 20:39:05 | ldlework | Araq: okay hold up on the PR |
| 20:39:08 | ldlework | I will think about that suggestion |
| 20:43:53 | * | boydgreenfield joined #nim |
| 20:46:27 | boydgreenfield | Araq: FYI just squashed and got you a clean styling PR. |
| 20:46:39 | boydgreenfield | (was on a flight earlier, sorry for the delay) |
| 20:52:25 | ldlework | boydgreenfield: do you know what I mean about not being able to pull out proc names as you scroll down the doc pages? |
| 20:52:42 | ldlework | because the syntax highlighted proc definitions are thin, and not very 'header' like? |
| 20:55:06 | boydgreenfield | Idlework: yes, I hear you. The challenge is that the proc names are styled the same way as all other identifiers – so they can’t be bolded/popped visually w/o either a) popping all the other types and the like; or b) changing how they’re classed. |
| 20:55:34 | boydgreenfield | Idlework: And by “can’t”, I really mean, “in playing around with it, I couldn’t get it to work in a way that looked nice and was a real improvement" |
| 20:55:38 | ldlework | I highly recommend bolding the proc names. |
| 20:55:53 | Araq | we should do b) |
| 20:56:43 | ldlework | And its not just proc's of course |
| 20:56:51 | ldlework | type names too |
| 20:56:52 | boydgreenfield | Happy to – that’s just a breaking change w/r/t the rST output, so I hadn’t wanted to muck about w/o others’ thinking it was necessary |
| 20:57:46 | boydgreenfield | Idlework: You mean in the types and consts sections? |
| 20:57:47 | ldlework | boydgreenfield: can't you do it with relative selectors? |
| 20:57:51 | ldlework | boydgreenfield: yeah |
| 20:57:57 | ldlework | pre > Identifier |
| 20:58:01 | ldlework | or rather |
| 20:58:05 | boydgreenfield | Idlework: Am playing around with that as we speak |
| 20:58:05 | ldlework | pre > Identifier:first-child |
| 21:04:22 | ldlework | I can't even get that font to be very bold at all |
| 21:05:01 | * | flaviu quit (Remote host closed the connection) |
| 21:06:33 | boydgreenfield | Idlework: Unfortunately, I think first-child is limited to the first child of pre, not the first instance of Identifier; but there’s surely another hacky way of doing this |
| 21:10:09 | * | flaviu joined #nim |
| 21:11:19 | ldlework | boydgreenfield: no way |
| 21:11:31 | boydgreenfield | ? |
| 21:11:38 | ldlework | boydgreenfield: pre foo:first-child, selects the first foo under pre |
| 21:12:29 | Araq | skyfex: afaict this issue has been resolved with the devel version of the compiler |
| 21:13:14 | boydgreenfield | Idelwork: unfortunately, I’m fairly sure it selects the foo *if* it’s the first-child (or at least that’s all I can get to directly work) |
| 21:13:20 | ldlework | boydgreenfield: http://codepen.io/anon/pen/bNexWr |
| 21:13:53 | ldlework | hmm |
| 21:14:09 | boydgreenfield | Idlework: I.e., “pre span.Identified:first-child” will *not* select ‘my_procname’ in <pre><span class=‘other’>proc</span> <span class=‘Identifier’>my_procname</span) |
| 21:14:14 | boydgreenfield | I’ll get it |
| 21:15:35 | ldlework | boydgreenfield: its first-of-type |
| 21:15:40 | ldlework | http://codepen.io/anon/pen/bNexWr |
| 21:15:49 | ldlework | :) |
| 21:16:26 | boydgreenfield | Idlework: Ah ha, well that’s much cleaner! I didn’t know of first-of-type before. |
| 21:16:32 | ldlework | me either! |
| 21:16:41 | ldlework | the web is getting better :) |
| 21:16:43 | ldlework | slowly |
| 21:16:59 | boydgreenfield | and phew |
| 21:17:00 | boydgreenfield | http://caniuse.com/#search=first-of-type |
| 21:17:18 | boydgreenfield | (incidentally you can get it to work by going through the cases with the + sibling operator, but that’s messy_ |
| 21:17:20 | boydgreenfield | *) |
| 21:20:39 | * | StefanSalewski joined #nim |
| 21:21:32 | * | boydgreenfield quit (Ping timeout: 250 seconds) |
| 21:22:00 | * | dyu quit (Quit: Leaving) |
| 21:23:56 | * | boydgreenfield joined #nim |
| 21:24:25 | StefanSalewski | No real progress understanding this "type time_t* {.importc: "time_t", header: "<sys/time.h>".} = int" seen in a cowboy-coders wrapper. Was curious because I used myself |
| 21:24:33 | StefanSalewski | time_t = int64 # generally 64 bit -- may we use times.Time ? |
| 21:25:11 | StefanSalewski | I think I will leave it as is it and wait until someone complains... |
| 21:27:00 | boydgreenfield | Idlework: Success. “dt pre > span.Identifier {special highlights}” and “dt pre > span.Identifier ~ span.Identifier {override those with inherit}”. Now onto what solves this problem... |
| 21:35:45 | StefanSalewski | OK, found something... |
| 21:36:06 | boydgreenfield | Idlework: Laptop battery is about to die, but here’s a working version with “popped” definitions. http://a.pomf.se/rwszyb.html |
| 21:36:31 | boydgreenfield | Idlework: I haven’t tried a lot of colors/weights/etc., but would you mind letting me know what you think could work? |
| 21:36:40 | boydgreenfield | I’ll check back in a few hours and then tweak and rebase my PR. |
| 21:37:22 | StefanSalewski | in module time.nim we have exactly the same: TimeImpl {.importc: "time_t", header: "<sys/time.h>".} = int |
| 21:38:16 | StefanSalewski | So indeed it should have some sense, and I will use time:Time for time_t then. Thanks. |
| 21:38:41 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:39:22 | Araq | StefanSalewski: I cannot help you as I don't understand your question. |
| 21:40:17 | StefanSalewski | The question was the meaning of the "= int" in the type definition. |
| 21:42:02 | ldlework | StefanSalewski: I thought we already went over it |
| 21:42:06 | ldlework | its the size of the type |
| 21:44:02 | StefanSalewski | I have to admit that I don't understand it. We define the time_t type using importc and at the same time = int assignment. |
| 21:44:38 | Araq | you cannot define a type using importc. |
| 21:44:49 | Araq | the definition reads like: |
| 21:45:08 | Araq | "Time is an alias for int. Oh btw codegen, map this to time_t." |
| 21:46:26 | Araq | and there are further gotchas here. 'importc' on types really only works reliably for nominal types. |
| 21:46:58 | Araq | otherwise the compiler is allowed to merge your type 'Time' with 'int' and lose the importc request |
| 21:47:57 | Araq | the compiler tries to not do that though, so TimeImpl is safe for now |
| 21:48:02 | StefanSalewski | Ok, now I understand better. I wonder still about int a bit, generally time_t should be 64 bit in nearly all cases following a discussion at stack overflow. |
| 21:48:20 | ldlework | StefanSalewski: yeah, on 64 bit machines |
| 21:48:25 | ldlework | in which case int *is* int64 |
| 21:48:51 | StefanSalewski | http://stackoverflow.com/questions/471248/what-is-ultimately-a-time-t-typedef-to |
| 21:49:29 | ldlework | StefanSalewski: Unix and POSIX-compliant systems implement the time_t type as a signed |
| 21:49:31 | ldlework | integer (typically 32 or 64 bits wide) which represents the number of seconds since the start of the Unix epoch |
| 21:49:47 | ldlework | StefanSalewski: how could a 32 bit machine rely on a type that can only be 64 bit? |
| 21:50:05 | StefanSalewski | Ok, thanks. I think I should not waste your time. We will proof it sooner or later. And module time.nim is fine. Thanks. |
| 21:50:27 | * | gour quit (Quit: WeeChat 1.0) |
| 21:50:57 | ldlework | StefanSalewski: you seem offended or something? |
| 21:52:12 | * | ldlework shrugs. |
| 21:58:26 | StefanSalewski | No. It's just not easy for my to understand all that. And I think it is really not that easy, see the question at stack overflow. But Araqs explanation helped. |
| 21:59:43 | StefanSalewski | And now I know that time_t definition is included in module time.nim, so I have not to worry any more. Sorry for missing that. |
| 22:00:41 | ldlework | StefanSalewski: you're basically saying: "Look at this stackoverflow that says time_t should be 64 bit!" |
| 22:01:16 | ldlework | The reason stackoverflow says that it should be 64 bit *****going forward in the future****** is to avoid Y2k36 errors when 2036 rolls around |
| 22:01:23 | ldlework | Not because POSIX defines time_t to be 64 bit. |
| 22:01:53 | ldlework | I don't know what part is hard for you to understand but 32bit machines **cannot** use native 64bit integers so this isn't even an option |
| 22:02:11 | ldlework | So even if you and I agree, "32bit time_t types will cause issues in the future" |
| 22:02:28 | ldlework | 32 bit machines have no way to just magically use 64 bit integers |
| 22:02:36 | ldlework | StefanSalewski: this is why in nim it is "= int" |
| 22:02:40 | Araq | ldlework: int64 works just fine on 32 bit machines |
| 22:03:02 | StefanSalewski | No. I really trust module time.nim more than stack-overflow. Stack-Overflow was one of my google results when I was looking for time_t definition ealier. |
| 22:03:03 | ldlework | Araq: huh |
| 22:03:25 | ldlework | Araq: so I can compile a binary on 64bit and just run it on 32bit machines? |
| 22:03:29 | ldlework | and it 'works just fine' ? |
| 22:03:30 | flaviu | ldlework: No. |
| 22:03:42 | flaviu | Because x64 has more registers and more instructions. |
| 22:03:56 | Araq | ldlework: it's true that the compiler needs to emit more instructions for these ops, but 'long long int' works on 32bit x86. |
| 22:04:07 | ldlework | I guess what I really mean to say is |
| 22:04:19 | ldlework | on a 32 bit machine, time_t is going to be compiled as a 32 bit integer |
| 22:04:25 | ldlework | and so Nim defines it as "= int" |
| 22:04:38 | ldlework | so that it matches whatever the native c lib is compiled to use |
| 22:04:42 | flaviu | But you can compile a program for both x86 and x86_64, the only difference is that i64s will be stored in two registers instead of one and that addition needs to be emulated. |
| 22:04:51 | ldlework | and that making it "= int64" is not going to work |
| 22:05:05 | ldlework | flaviu: Araq I understand now, thanks |
| 22:05:17 | Araq | not really. Nim defines it as 'int' because we found that is the best heuristic for the time being |
| 22:05:25 | ldlework | what does that mean? |
| 22:05:47 | Araq | 32bit Linux may map time_t to 64 bits |
| 22:06:10 | Araq | 32bit Solaris may map it to 32 bits |
| 22:06:12 | ldlework | Araq: but only because something more fundamental is set to use 64 bits right? |
| 22:06:31 | ldlework | and so whatever that is, is the same thing that will inform Nim what to use for 'int' ? |
| 22:07:01 | Araq | the definition is like "meh, pretend it's int, that's not too bad and rely on the codegen to emit time_t which is always correct" |
| 22:08:45 | StefanSalewski | OK, Araq, thats makes it even more clear to me. |
| 22:12:06 | Araq | also note that often the old OS version defined it to 32bits whereas never versions define it to 64bit |
| 22:12:48 | Araq | and on windows ofc it also depends on the used C compiler |
| 22:13:12 | * | kmcguire quit (Ping timeout: 245 seconds) |
| 22:14:33 | EXetoC1 | ldlework: what to use for int? the size of int is that of a pointer |
| 22:15:51 | Araq | StefanSalewski: and you're right, times.Time is what you should use for time_t in wrappers. |
| 22:17:29 | * | shevy left #nim ("I'll be back ... maybe") |
| 22:17:33 | EXetoC1 | ldlework: 32 bits on 32-bit architectures and 64 bits on 64-bit architectures |
| 22:17:43 | ldlework | EXetoC1: that's what I was saying |
| 22:17:49 | ldlework | int will be defined to be whatever the arch is |
| 22:18:12 | ldlework | so I was assuming that time_t would also be defined as whatever the arch is |
| 22:18:21 | ldlework | but I guess that is configurable |
| 22:18:32 | EXetoC1 | ok. I couldn't understand what you meant |
| 22:18:37 | * | EXetoC1 is now known as EXetoC |
| 22:19:04 | ldlework | I'll just stop trying to put forth my own explanations and saying anything for certain. |
| 22:19:06 | ldlework | never goes well |
| 22:20:52 | fowlmouth | whats up nims |
| 22:26:13 | * | StefanSalewski quit () |
| 22:41:43 | * | Trustable joined #nim |
| 22:52:37 | * | kmcguire joined #nim |
| 22:58:41 | * | yglukhov__ quit (Read error: Connection reset by peer) |
| 22:59:17 | * | yglukhov__ joined #nim |
| 23:10:43 | * | tinAndi joined #nim |
| 23:22:43 | * | willwillson joined #nim |
| 23:45:29 | * | boydgreenfield joined #nim |
| 23:48:14 | * | vendethiel quit (Quit: q+) |
| 23:50:12 | * | yglukhov__ quit (Read error: Connection reset by peer) |
| 23:50:39 | * | j3rky joined #nim |
| 23:50:45 | * | yglukhov__ joined #nim |
| 23:55:43 | * | kmcguire quit (Ping timeout: 250 seconds) |