|
gonadic io posted:i forget the exact syntax, but it was along the lines of what the gently caress
|
# ? Jan 12, 2016 03:13 |
|
|
# ? May 8, 2024 08:40 |
|
navigational url routing systems bad
|
# ? Jan 12, 2016 03:13 |
|
Snapchat A Titty posted:teacher wont allow it burn that loving teacher at the stake if it won't allow display: flex
|
# ? Jan 12, 2016 03:24 |
|
like who designs that routing system and says hmm yes ship it
|
# ? Jan 12, 2016 03:48 |
|
fleshweasel posted:burn that loving teacher at the stake if it won't allow display: flex wtf ( http://flexboxfroggy.com/ example 11: "Notice that when the flex direction is a column, justify-content changes to the vertical and align-items to the horizontal." )
|
# ? Jan 12, 2016 03:55 |
|
Mr Dog posted:http://danluu.com/ dan luu was in my hacker school (now recurse center) batch and is one of the smartest people I have ever met. his blog is awesome
|
# ? Jan 12, 2016 03:56 |
|
abraham linksys posted:hacker school ... one of the smartest people I have ever met. so what was he doing there
|
# ? Jan 12, 2016 04:08 |
|
learning things
|
# ? Jan 12, 2016 05:22 |
|
craisins posted:the shittiest part about flex is that when you change from horizontal to vertical displaying of poo poo, justify and align also change meaning flexbox uses deliberately agnostic terms for main axis and perpendicular axis alignment. it is the right decision.
|
# ? Jan 12, 2016 08:28 |
|
somebody needs to write a dark souls is completely fair blog to finish the lobsters trifecta
|
# ? Feb 7, 2016 04:38 |
|
souls are like a burrito
|
# ? Feb 7, 2016 04:50 |
|
how recent are the pl books in your company's bookshelf? i just looked at some books and some AJAX (Asynchronous JavaScript And XML) book from like 2006 was pretty much the most recent one. there's books for J2EE from 2003 and also some c++ windows programming book (32 bit programs ) from 1997 i could understand holding on to old books if they were more general purpose, but poo poo like that is just completely useless.
|
# ? Feb 10, 2016 13:48 |
|
Wheany posted:how recent are the pl books in your company's bookshelf? Like every excel installation, and thus every plugin, is 32bit so its still relevant! For some reason the address space is like 1.3gb though instead of 2
|
# ? Feb 10, 2016 14:45 |
|
petzold's programming windows 5th edition is a book everyone should have
|
# ? Feb 10, 2016 14:59 |
|
Wheany posted:how recent are the pl books in your company's bookshelf? we had a massive department-wide cleanup recently and got rid of all the really worthless volumes, of which there were seemingly hundreds (all the good stuff is on people's desks or locked in cupboards obviously) one highlight was O'Reilly's "The Whole Internet", from an era when the whole internet apparently fitted into a book one inch thick also dozens of copies of Java In A Nutshell (Java 1.2, obviously)
|
# ? Feb 10, 2016 15:15 |
|
gotta have a fat shelf of unreadable ActiveX OLE & COM shite to trigger the elders* *me
|
# ? Feb 10, 2016 15:21 |
|
i am physically unable to read programming related books past like the first chapter
|
# ? Feb 10, 2016 15:56 |
|
pointsofdata posted:Like every excel installation, and thus every plugin, is 32bit so its still relevant! For some reason the address space is like 1.3gb though instead of 2 the bottom 64 kb is normally unusable, then come the process parameters and the main heap (no particular reason they're here, it's just the first pages allocated so they end at the bottom), then the main executable, application DLLs, then there's the big free space you are using, then there are basically unmovable system DLLs, an unmovable per-process page and an array of unmovable per-thread pages, then comes an unmovable system-wide page (contains things like the system time, tick counter, system directory path etc.), and another 64 kb hole at the very top of the first 2 GB. if you have a 64 bit kernel, and a "large address aware" 32 bit program, the upper 2 GB become available and completely free of holes or reserved pages. if you have a 32 bit kernel, you can pass the kernel the /3GB switch at boot to get just the first half of the upper 2 GB, leaving only the uppermost GB to the kernel
|
# ? Feb 10, 2016 16:12 |
|
guy writing medical imaging software needed to reserve a big contiguous chunk of memory, so I told him to move all code to a DLL, statically link it from a dummy executable, give the dummy executable a huge array of zeros of the size he needed, and in the main (now moved to the DLL) unmap the main executable to free up the space for allocation. he did, it worked, and in my honor he hid a heavily obfuscated bitmap of a bunny somewhere in the code. kids, don't do this at home
|
# ? Feb 10, 2016 16:17 |
|
why is the dll needed in that procedure, just making the executable require the entire chunk seems the entire solution?
|
# ? Feb 10, 2016 16:18 |
|
Cybernetic Vermin posted:why is the dll needed in that procedure, just making the executable require the entire chunk seems the entire solution? you can use the standard virtual page allocator instead of coding an allocator that operates off the reserved array e: it was a clusterfuck with literally hundreds of DLLs, this was the cleanest solution hackbunny fucked around with this message at 16:26 on Feb 10, 2016 |
# ? Feb 10, 2016 16:21 |
|
I triggered a hackbunny windows post,this is my proudest forums moment
|
# ? Feb 10, 2016 21:30 |
|
hackbunny posted:the bottom 64 kb is normally unusable, then come the process parameters and the main heap (no particular reason they're here, it's just the first pages allocated so they end at the bottom), then the main executable, application DLLs, then there's the big free space you are using, then there are basically unmovable system DLLs, an unmovable per-process page and an array of unmovable per-thread pages, then comes an unmovable system-wide page (contains things like the system time, tick counter, system directory path etc.), and another 64 kb hole at the very top of the first 2 GB. if you have a 64 bit kernel, and a "large address aware" 32 bit program, the upper 2 GB become available and completely free of holes or reserved pages. if you have a 32 bit kernel, you can pass the kernel the /3GB switch at boot to get just the first half of the upper 2 GB, leaving only the uppermost GB to the kernel I take it excel is not large address aware then distortion park fucked around with this message at 21:33 on Feb 10, 2016 |
# ? Feb 10, 2016 21:30 |
|
excel might be large address capable, but there's probably a legion of lovely business COM objects that aren't. isn't there a special 64 bit version of Excel you can install?
|
# ? Feb 10, 2016 21:53 |
|
pseudorandom name posted:excel might be large address capable, but there's probably a legion of lovely business COM objects that aren't. yeah, "large address aware" is one of those flags copied from the main executable to the process, and if your program is the kind that loads DLLs dynamically, like plugins, those flags affect all DLLs. if your plugins have a history of not working with pointers >2GB, you play it safe and disable that flag, because it's not the kind of flag that can be disabled on the fly when you load an incompatible DLL, like say DEP. you'd have to run dumpbin on the excel executable to know for sure if that's what they're doing, though anyway raymond chen has written at length about large address awareness, and more rigorously than I have
|
# ? Feb 10, 2016 22:20 |
|
if worst comes to worst you can drive excel from the outside, as an out-of-process OLE server, or (comedy option) as a DDE target, have a separate address space and do whatever you want. or you can make your plugin itself an out-of-process server, I think only shell extensions are specifically limited to STA inproc, but that's because the shell historically didn't use OLE (grep the Windows 2000 source leak for "piggy" for lols) but simulated (or duplicated, see shell namespace vs OLE monikers) a lightweight subset of it
hackbunny fucked around with this message at 22:28 on Feb 10, 2016 |
# ? Feb 10, 2016 22:24 |
|
having your in-proc plugin just be a wrapper for an out-of-process server is just generally a good idea regardless of what you're writing a plugin for
|
# ? Feb 10, 2016 22:48 |
|
Plorkyeran posted:having your in-proc plugin just be a wrapper for an out-of-process server is just generally a good idea regardless of what you're writing a plugin for if the interfaces between application and plugin are marshallable (which requires no effort if they're dispinterfaces, i.e. dynamically invokable and only using OLE automation types in function arguments/return values), COM can make it "painless" because then the wrapper DLL is COM itself
|
# ? Feb 10, 2016 23:03 |
|
pseudorandom name posted:excel might be large address capable, but there's probably a legion of lovely business COM objects that aren't. There is a 64bit bit version but none of our clients will install it because other lovely plugins won't work with it, and you can't install it side by side with 32bit
|
# ? Feb 10, 2016 23:30 |
|
Plorkyeran posted:having your in-proc plugin just be a wrapper for an out-of-process server is just generally a good idea regardless of what you're writing a plugin for this is what should have happened right at the start, sasly it didnt
|
# ? Feb 10, 2016 23:31 |
|
pointsofdata posted:There is a 64bit bit version but none of our clients will install it because other lovely plugins won't work with it, which is literally one of the best reasons to use it.
|
# ? Feb 11, 2016 00:53 |
|
tef posted:let's try to make code easy to delete this awful post became this awful post http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
|
# ? Feb 13, 2016 16:11 |
|
quote:Thank you to all of my proof readers for your time, patience, and effort. Please change this to Thank you to Sam Altman, John Carmack, Hillary Clinton, and Rudolf Hess for reading drafts of this.
|
# ? Feb 13, 2016 22:41 |
|
tef posted:this awful post became this awful post http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to too bad step 6 wasn't the last one for the obvious lovely pun.
|
# ? Feb 13, 2016 23:12 |
|
i edited out a zombocom reference
|
# ? Feb 14, 2016 03:00 |
|
tef posted:this awful post became this awful post http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to cake42 1 hour ago “Every line of code is written without reason, maintained out of weakness, and deleted by chance” Jean-Paul Sartre’s Programming in ANSI C. I just started the article and I already have problems with it, not a good sign. While it may be obvious when you research the timelines of JPS (he died a few years before ansi c 89 was established) and C , not to mention the miles of metaphorical distance between Computer Programming and JPS's work) . I guess the author was trying to be cute?? but that fabrication should be made clear as such. he's undermining his own inherent credibility as an author, however much the reader decides to put in. Serious problem in my book.
|
# ? Feb 14, 2016 18:00 |
|
fritz posted:cake42 1 hour ago lol programmers are terrible
|
# ? Feb 14, 2016 18:11 |
|
fritz posted:cake42 1 hour ago COMPILATION ERROR: jean paul sartre actually didn't write that beep boop
|
# ? Feb 14, 2016 18:30 |
|
I liked that line, don't let cake 42 get to you man
|
# ? Feb 14, 2016 21:26 |
|
|
# ? May 8, 2024 08:40 |
|
Symbolic Butt posted:COMPILATION ERROR: jean paul sartre actually didn't write that beep boop
|
# ? Feb 14, 2016 22:43 |