00:22:58  * RT|Chatzillajoined
00:24:10  * cjdquit (Ping timeout: 256 seconds)
01:27:26  * AtumTquit (Remote host closed the connection)
01:31:12  * cloudshuquit (Quit: Connection closed for inactivity)
02:27:12  * xaxxonjoined
04:11:07  * bradleymeckjoined
04:16:08  * bradleymeckquit (Quit: bradleymeck)
05:26:54  * zvjoined
07:00:37  * xaxxonquit (Quit: xaxxon)
07:01:37  * plutoniixjoined
08:02:33  * plutoniixquit (Ping timeout: 240 seconds)
08:07:23  * hatf0joined
08:09:14  * xaxxonjoined
08:09:48  <hatf0>x-post from #node-dev but i'm having a weird issue where the cstring returned from *v8::String::Utf8Value manages to "disappear" leaving nonce/random stuff in it's wake after being stored in a variable
08:09:50  <hatf0>https://pastebin.com/Smyhc8W3
08:12:00  <hatf0>does anybody have a clue on this? running v8 6.5 release on wine (yes i know there exists a linux build but the implementation is for a windows application)
08:12:55  <hatf0>https://cdn.discordapp.com/attachments/226544945887051779/416862068675837953/2018-02-24-004026_338x99_scrot.png here's an example of the bug.. the line should be printing out HOST:
08:15:43  * plutoniixjoined
08:17:16  * plutoniixquit (Max SendQ exceeded)
08:17:44  * plutoniixjoined
08:18:42  * plutoniixquit (Max SendQ exceeded)
08:20:37  * plutoniixjoined
08:34:40  * xaxxonquit (Quit: xaxxon)
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:41  * mylesborinsjoined
11:54:04  * AtumTjoined
13:26:45  * bradleymeckjoined
13:59:10  * plutoniixquit (Ping timeout: 264 seconds)
13:59:40  * plutoniixjoined
14:08:59  * cjihrig_joined
14:10:29  * cjihrigquit (Ping timeout: 264 seconds)
14:15:38  * bradleymeckquit (Quit: bradleymeck)
14:23:43  * bradleymeckjoined
14:31:27  * bradleymeckquit (Ping timeout: 264 seconds)
14:32:37  * bradleymeckjoined
15:14:48  * bradleymeckquit (Quit: bradleymeck)
15:21:23  <devsnek>hatf0: you have to copy the string
15:21:32  <devsnek>thats how i do it anyway
15:21:40  <devsnek>there's probably some secret
15:24:25  <joyee>const char* cstr = *v8::String::Utf8Value(str);
15:25:47  <joyee>Doesn't this go out of scope immediately?
15:26:25  <joyee>The Utf8Value
15:27:18  <joyee>You'll need to assign it to a local variable so it's still in the scope
15:28:58  <devsnek>well its still in scope for the printf right?
15:29:12  <devsnek>i only ran into this issue while passing stuff around between threads
15:30:06  <joyee>Doing something like `const char* cstr = *v8::String::Utf8Value(str);` means the ~Utf8Value will be run almost as soon as it is created
15:31:18  <devsnek>how so
15:31:44  <devsnek>you mean cuz you do operator(*) inline?
15:31:53  <joyee>Yep
15:31:59  <devsnek>that makes a lot of sense kek
15:32:39  <joyee>Try assigning the Utf8Value to a local variable
15:32:42  <devsnek>hatf0: there's your answer
15:32:44  <joyee>then do *
16:27:46  * AtumT_joined
16:30:33  * AtumTquit (Ping timeout: 240 seconds)
16:41:18  * AtumTjoined
16:41:35  * AtumT_quit (Ping timeout: 240 seconds)
16:57:51  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
17:02:02  * AtumT_joined
17:02:27  * AtumTquit (Ping timeout: 240 seconds)
17:27:57  * austincheneyjoined
17:28:19  <austincheney>either my thoughts on lexical scope are wrong or there is a bug in V8. If a function has a recursive call are its locally declared references lexically available to the recursive instances in a lexical fashion?
17:29:37  <austincheney>For example lets say I declare a reference as myString = ""; but later assign a longer value to that reference `myString = "somethingLonger";` just before making a recursive call
17:30:15  <austincheney>What value should the recursive instance see for the reference after the declaration point: "" or "somethingLonger" ?
17:38:54  <austincheney>here is the function in question https://github.com/prettydiff/prettydiff/blob/3.0.0/api/node.ts#L311-L347
17:39:15  <austincheney>what is curious is that the described behavior differs for the numbers from the string reference
17:41:27  <austincheney>The number types are reassigned to the declared value, 0, at each function call. The string value persists through the recursive calls as though the recursive calls are lexically nested and the string reference "comm" is only declared at the highest level (never redeclared in a lower scope)
17:44:01  <austincheney>An example run of the mentioned code: 1. clone the code down. 2. run the typescript build `tsc` on the directory. 3. run the project build `node js/build` 4. run `node js/api/node options mode`
17:45:31  <austincheney>disregard... i found the cause of my code defect
18:15:29  <hatf0>we’ll see
18:15:41  <hatf0>well see* the bug is strictly platform specific
18:16:33  <hatf0>and thanks guys, i’ll see if that helps
18:20:07  <hatf0>also joyee: on Windows am i just strictly running against the clock for the destructor to be called? i know i can strcpy the cstring before it disappears or wrap it in a local handle but the issue is actually non existent on windows entirely
18:21:20  <hatf0>regardless it makes sense, thanks for your help, though
18:21:53  <joyee>I guess that depends on your compiler settings, maybe you have the debug flag on and msvc (if you use that) do not actually put garbage in a freed block of memory that quick
18:24:26  <hatf0>i guess seeing as the memory management models for *nix and windows are vastly different that makes sense
23:17:42  * RT|Chatzillajoined
23:57:20  * hatf0quit
23:57:29  * hatf0joined