This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Adriweb
Pages: 1 ... 10 11 [12] 13 14 ... 115
166
« on: August 12, 2014, 10:29:48 am »
It was the pastebin on the IRC PM  But anyway, I forum-PM'd you ^^
167
« on: August 11, 2014, 07:51:34 pm »
down to 500 bytes with no true-randomness as well as no check for spawn location
With both, 613 bytes >.<
Anyway, submitted.
GL HF
Edit : 596 bytes;
168
« on: August 11, 2014, 06:16:52 pm »
I will, however, have to see an animated screenie of any entries of Nspire Lua and any other language I can't test.
My code works on Jim's js Nspire-Lua tester ^^ http://bwns.be/jim/WEBspire/editor.html(edit : well, there's a weird behaviour on some modulus cases, though  - the snake simply decides to vanish from the screen ) Also, down to 523 bytes Edit : 522 Edit : 517 Edit : 502
169
« on: August 11, 2014, 05:52:55 pm »
I got a working one at 533 bytes in Nspire-Lua.
Still working on it.
Also, just to be sure : we loose whenever the head of the snake touches any part of its body, right ?
(that's what I did anyway)
170
« on: August 11, 2014, 12:15:32 pm »
Ha ! Why didn't I try with gsub I did too complicated with gmatch trying to do everything within a single call... ^^
171
« on: August 10, 2014, 08:18:20 pm »
@LDStudios : eh, too bad, I deleted it. But the core of it is the same as my function-based code so you'll be able to see that. Also, I had a nice looking solution with pattern matching instead of loops but it's several bytes longer, so...
172
« on: August 10, 2014, 05:54:51 pm »
But you do it char by char so it's not the same Anyway, your way, I got a bit more than you so I won't submit it ^^ Also, made one in C that's 143 chars + length of input string.
173
« on: August 10, 2014, 04:13:44 pm »
got a 113 chars in Lua ^^
174
« on: August 07, 2014, 06:05:44 pm »
Nope, that was the calculator program. The generator is still up and working. (Edit : Also, thanks )
176
« on: August 06, 2014, 04:35:00 am »
Anyway, the format is known enough for several third-party tools (Eried's program, Critor's mViewer GX Generator, for example...) to generate valid files, so there's that. If the unsupported parts are actually not necessary and not long-term safe, well, we may not need to take time to understand them, it wouldn't be useful 
177
« on: August 05, 2014, 07:24:05 am »
Hi, Thanks for the info - the link you gave has some info about the program format as seen by [MOHPC] member Eried - maybe it was only on simple programs, indeed, I don't know. However, it may be enough for file transfers. One would have to check with complex programs, though, with his program (see https://github.com/eried/PrimeComm/blob/master/PrimeLib/PrimeUsbFile.cs ) If you still have a tiny bit of motivation, you're welcome to register on the wiki you linked and try editing on the sandbox for example (you can try anything there, it won't matter). If you decide to do that and edit/contribute to the file format page, let us know (just reply here telling so), otherwise we can wait for a bit (maybe people will have some suggestions) and then edit it ourselves from what you've posted here
178
« on: August 03, 2014, 08:21:24 pm »
I still can get the OSUpdate.dll, so there's no problem after that (I haven't tried, though, but once we have the .dll ...)
179
« on: August 03, 2014, 07:26:54 pm »
I understand, but wouldn't those variables be localized on a lower level, so that everytime when I call them on a higher level, they have to be loaded into the ligher level which takes time? Or do the different levels make no difference? What about just writing local math=math at the beginning of the script, would then all math functions be as fast accessible as if I localize them individually? Argh, I actually had benchmarks recently but I can't get them right now - I was experimenting with different scopes and globals/locals (it was to determine the best way to localise (as in multilingual, this time ) strings and use them efficently). I'll try to get that soon (I told Jim about the results, so maybe he still has that conversation in his IRC logs) In the meantime, look at this : http://www.lua.org/gems/sample.pdf and http://stackoverflow.com/a/4646957 (and other links on Google when you search for 'lua optimization local' with no quotes) IIRC, the reason why locals are faster is because global access (through _G) is done by hash, whereas local access is by index, and that's much faster. And btw. I noticed that the localizing itself takes time, so if you call a math function only once, it seems be faster not to localize it. Oh yes, sure, when used once (or a few times, even), you really don't have to worry about it. It's "only" when functions/variables are called very often that the difference between globals and locals start to get noticeable. So, that tends to be very useful for calculations (big for loops, for example), and fast timer funcs.
180
« on: August 03, 2014, 07:11:31 pm »
( Note that I was especially talking about the math functions ) Well, I didn't say "bad"  However... I wrote "mistake" because I suppose it is (?) since he apparently knows about the localizing trick The reason why I think it's a mistake (ans worth mentionning in this case) is because it's within a tick() function that gets called often by the timer and re-localizing these each time are pointless (the math functions aren't gonna change ) so it can only waste (a little) time at each tick. But in other circumstances, one would have to analyse more deeply the code to tell if it's needed or not, I obviously agree Anyway, the main point is to reduce to the maximum the number of things that the tick function(s) have to do ! Oh by the way, I also saw something like : function foo() ... end local foo = foo. It's probably more efficient to directly do local function ... (but I doubt any difference will be felt - at least it's cleaner ^^)
Pages: 1 ... 10 11 [12] 13 14 ... 115
|
Show Posts
