|
stoops posted:Notepad++ experts Paul MaudDib posted:capture group method \r?\n(?!\d\d/\d\d/\d\d ) uses negative lookahead to search for "new line not followed by a date". This will also get rid of blank lines (including a file-ending new-line). Paul's find masks would instead be \r?\n([A-Za-z]) and \r?\n(..[^/])
|
# ? Oct 13, 2017 15:28 |
|
|
# ? May 31, 2024 01:26 |
|
What markup language uses '@@' to mark code blocks? Like:code:
|
# ? Oct 15, 2017 19:55 |
|
Thermopyle posted:What markup language uses '@@' to mark code blocks? Like: Looks like Razor syntax from ASP.net.
|
# ? Oct 15, 2017 20:56 |
Anyone remembers what was that one book for windows desktop development from ~20 years ago called? I'm almost sure it was one well-written title that many windows desktop devs at the time had. edit: yeah I think it was http://www.charlespetzold.com/pw5/ Shy fucked around with this message at 13:48 on Oct 16, 2017 |
|
# ? Oct 16, 2017 13:29 |
|
Mr Shiny Pants posted:Looks like Razor syntax from ASP.net. Razor doesn't use double @s
|
# ? Oct 16, 2017 13:50 |
|
Mr Shiny Pants posted:Looks like Razor syntax from ASP.net. Thanks, it turns out that it's something custom this one dev wrote to do code blocks in markdown. Don't know their problem with triple back ticks...
|
# ? Oct 16, 2017 14:06 |
|
Tea Bone posted:Is there a way in rails/ruby to create a method on the fly which returns a string rather than a no method error? Tea Bone posted:Thanks, this nearly gets me there but only works on foo.nonexisitngmethod not foo.bar.method when foo.bar is nil. I suppose extending the nil class with method_missing might do it though! MALE SHOEGAZE posted:This will work but strongly consider whether another approach is possible. Method missing will make your life miserable. Sorry for the late reply, but I'd also recommend against changing NilClass. I'm not sure what you mean by creating a method on the fly, but have you considered using the try() method? It allows you to try invoking a method or reference on an object, but returns nil if it doesn't exist, instead of giving an error. So, if foo.bar is nil, foo.bar.try(:name) returns nil. You still have to catch the nil response, so I'm not sure if it saves any steps logically, but at least you're not using error handling for flow control. (If you aren't even sure foo is correctly populated, you can use foo.try(:bar).try(:name), though foo needs to at least exist.) If you're using nested hashes, you can use dig() analogously. Also, there's a Ruby on Rails thread you can use, if you want more specialized knowledge.
|
# ? Oct 16, 2017 16:11 |
|
So I've never worked with JS before and for my own education I'm trying to look through some of the JS a colleague wrote in our new project:code:
Linear Zoetrope fucked around with this message at 19:30 on Oct 16, 2017 |
# ? Oct 16, 2017 19:28 |
|
Linear Zoetrope posted:So I've never worked with JS before and for my own education I'm trying to look through some of the JS a colleague wrote in our new project: The event processing loop is dupersaurus fucked around with this message at 19:36 on Oct 16, 2017 |
# ? Oct 16, 2017 19:32 |
|
dupersaurus posted:The event processing loop is So I assume that the Websocket construction is secretly modifying some lower-level global state in the browser context or spawning something akin to another thread (I know JS doesn't have threads but I'm saying something async running its own loop even if it's scheduled on a single thread)? Nice to know returning from main doesn't terminate the program in JS I guess. (Or, more accurately, when it hits the end of the script, since the file just ends after main();)
|
# ? Oct 16, 2017 19:52 |
|
Linear Zoetrope posted:So I assume that the Websocket construction is secretly modifying some lower-level global state in the browser context or spawning something akin to another thread (I know JS doesn't have threads but I'm saying something async running its own loop even if it's scheduled on a single thread)? Nice to know returning from main doesn't terminate the program in JS I guess. Presumably the websocket object does something that keeps it out of the jaws of the garbage collector, yes. Also worth noting that that the function is called main has no special meaning to javascript.
|
# ? Oct 16, 2017 19:57 |
|
dupersaurus posted:Presumably the websocket object does something that keeps it out of the jaws of the garbage collector, yes. Hence why I said, more accurately when it hits the end of the script. Because it declares a main function and then just calls main at the end of the script. I was likening it to, say, code:
|
# ? Oct 16, 2017 19:58 |
Linear Zoetrope posted:Hence why I said, more accurately when it hits the end of the script. Because it declares a main function and then just calls main at the end of the script. I was likening it to, say, Isn't the dealer variable global?
|
|
# ? Oct 16, 2017 20:04 |
|
Shy posted:Isn't the dealer variable global? Still, in Python if you do code:
|
# ? Oct 16, 2017 20:12 |
A global variable exists for as long as the context that created it, and the referenced object doesn't get destroyed as long as it's being referenced, so assuming the context is persistent (browser page?) the object persists too.
|
|
# ? Oct 16, 2017 20:15 |
|
Shy posted:A global variable exists for as long as the context that created it, and the referenced object doesn't get destroyed as long as it's being referenced, so assuming the context is persistent (browser page?) the object persists too. Well, right, but something, somewhere, has to be doing something along the lines of (pseudocode): code:
code:
Linear Zoetrope fucked around with this message at 20:25 on Oct 16, 2017 |
# ? Oct 16, 2017 20:23 |
|
Shy posted:A global variable exists for as long as the context that created it, and the referenced object doesn't get destroyed as long as it's being referenced, so assuming the context is persistent (browser page?) the object persists too. The scope is the main function. Nothing outside of it (assuming var dealer doesn't appear in the global scope). Even if you're treating main as an object constructor, dealer isn't a member property, it's just there in the ether of the closure (the functions defined on dealer do technically have access to the dealer object). Edit: Linear Zoetrope posted:Well, right, but something, somewhere, has to be doing something along the lines of (pseudocode): Yes, WebSocket it itself listening to its own set of callbacks (I'm not familiar with the websocket api so I couldn't tell you what exactly the callbacks are). That you haven't explicitly defined every callback isn't a problem, it happens all the time in JS. dupersaurus fucked around with this message at 20:28 on Oct 16, 2017 |
# ? Oct 16, 2017 20:25 |
|
dupersaurus posted:The scope is the main function. Nothing outside of it (assuming var dealer doesn't appear in the global scope). Even if you're treating main as an object constructor, dealer isn't a member property, it's just there in the ether of the closure (the functions defined on dealer do technically have access to the dealer object). Sorry, var dealer does appear in the global before all the function declarations so I missed it.
|
# ? Oct 16, 2017 20:26 |
dupersaurus posted:The scope is the main function. Nothing outside of it (assuming var dealer doesn't appear in the global scope). Even if you're treating main as an object constructor, dealer isn't a member property, it's just there in the ether of the closure (the functions defined on dealer do technically have access to the dealer object). Implicitly declared JS variables are global. If var dealer doesn't appear inside the function, it's a globally accessible variable.
|
|
# ? Oct 16, 2017 20:30 |
|
dupersaurus posted:The scope is the main function. Nothing outside of it (assuming var dealer doesn't appear in the global scope). Even if you're treating main as an object constructor, dealer isn't a member property, it's just there in the ether of the closure (the functions defined on dealer do technically have access to the dealer object). What I'm saying is there's a potential problem in like code:
|
# ? Oct 16, 2017 20:31 |
|
Linear Zoetrope posted:What I'm saying is there's a potential problem in like If you set the callbacks right after opening the connection there is no concern, this is standard JS usage. It's (presumably) all asynchronous, JS is going to have its callbacks long before the connection is opened.
|
# ? Oct 16, 2017 20:36 |
|
I think this might be helpful in just giving you a better understanding overall on how the JS event loop engine works. https://www.youtube.com/watch?v=8aGhZQkoFbQ Your while(true) would be more or less the event queue that holds all the registered callback functions listening for specific events, if I'm understanding your question/problem correctly. reversefungi fucked around with this message at 20:41 on Oct 16, 2017 |
# ? Oct 16, 2017 20:39 |
|
Linear Zoetrope posted:
Your addToContext is just implied with lots of callback-focused browser APIs. You don't have to set up your own loop for all sorts of event listeners.
|
# ? Oct 16, 2017 21:00 |
|
The Dark Wind posted:I think this might be helpful in just giving you a better understanding overall on how the JS event loop engine works. Yeah this helps, I guess I'm just used to languages that are a bit more explicit than Javascript. This reminds me a bit of the secret SDL_main event loop you get generated for you in SDL programs.
|
# ? Oct 16, 2017 21:04 |
|
IMO a lot of the JS APIs and language constructs are absurdly flimsy attempts to convince people they're not actually using a *gasp* functional language and, oh hey look at that, it's confusing to someone coming from a background of any other language whoda' thunk. However, you really are hooking into the behavior of an implicitly running program, much like talking to an operating system via event handlers, so an addToContext() would seem out of place to me over a start() or beginConnection() method. Conceptually, the context handed you an object, so it knows it's there and you don't have to add it to anything. That's not obvious, though because of the new keyword which makes less lense (to me!) than making you, say, call a getWebSocket on window or something.
|
# ? Oct 16, 2017 21:28 |
|
In fairness, the way it handles this is actually pretty neat all things considered. It's a pretty sound system for writing a language that's primarily meant to be handling programs that are largely going to respond to user input and external events rather than doing their own thing. It's just not at all what I was expecting given my background in more OpenGL sorta graphics and UI programming.
Linear Zoetrope fucked around with this message at 11:22 on Oct 17, 2017 |
# ? Oct 16, 2017 21:36 |
|
I think what Linear Zoetrope's getting at is the code basically creates a thing, then configures it, but then there's no explicit "ok I've set this up now, let it run" command. It feels sketchy because now you're sort of racing the Websocket, building it while it's already in motion and assuming everything will be in place before it's needed If there's some kind of caching in place that makes the object instantly return a result then anything could happen. Maybe this isn't an issue with JavaScript's event loop model but it definitely feels weird from the outside
|
# ? Oct 16, 2017 22:30 |
|
I'm working through this certification right now for work https://academy.microsoft.com/en-us/professional-program/tracks/data-science/ I have zero programming experience (unless you count writing up SQL and SAS queries in undergrad). I have an MBA, work in corp finance for a tech company, and I want to learn some more advanced data manipulation and enter the world of machine learning (our company sells machine learning solutions, among other things). My question is, which is going to be more helpful to learn, Python or R? The stuff I looked up has told me that for general data-sciencey stuff, unless you already know which tool you must use, it doesn't matter which one you use. Is that accurate? I'm leaning more towards R because I expect that all the things I do will be work-related, data science stuff.
|
# ? Oct 16, 2017 22:59 |
|
canyoneer posted:I'm working through this certification right now for work
|
# ? Oct 17, 2017 12:56 |
|
canyoneer posted:I'm working through this certification right now for work In your situation I think R is the better choice. The language is build around working with data and doing general data-sciencey stuff and has tons of tools for it. In my opinion it's also quite a bit more easy to learn as a non-programmer. At my university I learned R for it's machine learning packages, but I now work in a bank and mostly use it to automate things my colleagues do in excel.
|
# ? Oct 17, 2017 14:18 |
|
Peristalsis posted:Sorry for the late reply, but I'd also recommend against changing NilClass. I'm not sure what you mean by creating a method on the fly, but have you considered using the try() method? It allows you to try invoking a method or reference on an object, but returns nil if it doesn't exist, instead of giving an error. So, if foo.bar is nil, foo.bar.try(:name) returns nil. You still have to catch the nil response, so I'm not sure if it saves any steps logically, but at least you're not using error handling for flow control. (If you aren't even sure foo is correctly populated, you can use foo.try(:bar).try(:name), though foo needs to at least exist.) Thanks, I had no idea that you could use try that way but that looks to be what I'm after. It actually turned out that 'bar' had far less attributes than I was expecting so I was able to just define bar_attribute in foo to return bar.attribute if bar existed or nil if not, but your suggestion looks like a much cleaner way of handling things.
|
# ? Oct 17, 2017 14:57 |
|
baka kaba posted:I think what Linear Zoetrope's getting at is the code basically creates a thing, then configures it, but then there's no explicit "ok I've set this up now, let it run" command. It feels sketchy because now you're sort of racing the Websocket, building it while it's already in motion and assuming everything will be in place before it's needed Yes, that's what I was getting at. It sure looks like you just created an object like you would in Java, but that's a ruse. What's actually happening is that function call returns an interface to an object managed by the environment. The new keyword just changes the context the function runs within slightly, in a way that might not even matter, depending on the implementation of the function you're calling.
|
# ? Oct 17, 2017 16:25 |
|
Well for me it's not the instantiation that's weird, it's that there's a kind of builder/config pattern going on without a final start call or whatever. I mean there's no reason you can't modify something that's already running, but it's usually best practice to initialise something before it's used, so nothing accesses it in some half-built state. This feels more like a yolo approach JavaScript's execution model might be simple enough that everything in the function is guaranteed to be run before anything else happens, I don't know! It definitely doesn't feel like a functional approach though
|
# ? Oct 17, 2017 19:48 |
|
Shy posted:Anyone remembers what was that one book for windows desktop development from ~20 years ago called? I'm almost sure it was one well-written title that many windows desktop devs at the time had.
|
# ? Oct 18, 2017 04:46 |
|
baka kaba posted:Well for me it's not the instantiation that's weird, it's that there's a kind of builder/config pattern going on without a final start call or whatever. I mean there's no reason you can't modify something that's already running, but it's usually best practice to initialise something before it's used, so nothing accesses it in some half-built state. This feels more like a yolo approach i think the missing piece here is that javascript is single threaded. nothing else *can* run until your script is finished, so nothing can hit those websocket’s callbacks until they have been set
|
# ? Oct 18, 2017 06:25 |
|
Gul Banana posted:i think the missing piece here is that javascript is single threaded. nothing else *can* run until your script is finished, so nothing can hit those websocket’s callbacks until they have been set For now (if some mad men have their way). IMO, Javascript's single-threaded event loop is one of its best features.
|
# ? Oct 19, 2017 00:43 |
|
Gul Banana posted:i think the missing piece here is that javascript is single threaded. nothing else *can* run until your script is finished, so nothing can hit those websocket’s callbacks until they have been set Yeah that's what I figured, it's just hidden because you create the Websocket (which involves executing some code before your function continues) and since you don't explicitly start it, it must be automatically queued up somewhere in the event loop. You're relying on it being absolutely definitely deferred until your setup function completes Is this a completely normal and safe assumption in JavaScript? Side effects will take place after your function ends? I mean I know a bit of JS but this kind of behaviour is a mystery
|
# ? Oct 19, 2017 00:56 |
|
Time to learn about Promises
|
# ? Oct 19, 2017 01:07 |
|
Oh sure, but with promises you're explicitly using that deferred construct, right? So it's clear that the event's result will be delivered after you supply the handlers, it's not just going to fire off into oblivion because you weren't quick enough But for non-promisey things, is there any guarantee that your callbacks will be added before the event that calls them happens, if you kick off the event in the same function like in the Websocket example? People are saying it's normal to do it this way, but I'm not sure if that's basically going "eh it's a network thing it shouldn't trigger a result for a while, this is an easy race", or if there's some formal universal guarantee in the language that it won't be started until the function ends, so it's really an idiom that keeps configuring things simple and safely takes care of initiating the thing afterwards. It feels like it's the former, but maybe there's some clever stuff happening instead? (That's a good link, thanks!)
|
# ? Oct 19, 2017 02:36 |
|
|
# ? May 31, 2024 01:26 |
|
From what I remember about the talk I posted previously, I'm pretty sure that the event queue (which is where all callbacks listening to events sit) does not start running until everything in the script has finished executing. So it would be more like the latter. https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=777s From the video: "The event loop has one simple job and it's to look at the stack and look at the task queue. If the stack is empty, it takes the first thing in the queue and pushes it onto the stack." reversefungi fucked around with this message at 02:45 on Oct 19, 2017 |
# ? Oct 19, 2017 02:40 |