code logs -> 2013 -> Sat, 30 Nov 2013< code.20131129.log - code.20131201.log >
--- Log opened Sat Nov 30 00:00:05 2013
00:00
< RichyB>
the other is called RestrictedPython. Zope2 uses it. It's on PyPi. I would seriously not use it for sandboxing because evilbungle (guy I know on through work, that's his handle on twitter and freenode) keeps finding ways to break out of the sandbox inside Zope2.
00:02
< RichyB>
<Derakon> And I'd rather not lull the users into a false sense of security. I like this pragmatism.
00:05
<&ToxicFrog>
Yeah, traditionally the answer is "you can't guard against this in any useful sense"
00:05
<&Derakon>
When it comes to security, if you can't do the job properly then you'd better not do it at all~
00:06
<&ToxicFrog>
The KSP devs have taken the approach of requiring all plugin authors to publish source code, which I am well in favour of, although it doesn't stop someone from posting source and then building the plugin from a different source.
00:06
<&Derakon>
Jetblade plugins would come in the form of Python modules, ergo automatically open-source.
00:06
<@Tarinaky>
It also doesn't guarentee anyone will audit the source.
00:07
<@Tarinaky>
Please ignore the code for sending an email with your credit card/passwords in - it's an optimisation. For speed!
00:14 AverageJoe [evil1@Nightstar-dfmuir.ph.cox.net] has quit [[NS] Quit: Leaving]
00:15
<&Derakon>
If Jetblade did take off and have a thriving plugin scene, then the way to handle malicious plugins would be to audit any plugin that did any imports -- since the vast majority of game mods should be doable without reference to libraries.
00:16
<&Derakon>
And the audit could be as simple as "You're importing sys; don't do that."
00:16
<&Derakon>
I'm pretty sure that code that doesn't do any imports can't cause any harm except by crashing your game.
00:17
<~Vornicus>
well -- it can. file is a builtin
00:17
<&Derakon>
Oh dear.
00:17
<@Tarinaky>
This being Python there's probably a way to access modules loaded into the session that aren't explicitly imported into the scope.
00:18
<&Derakon>
There's no "session" in a proper Python program, at least not in that sense.
00:18
<@Alek>
the part of me that's a 12 year old keeps giggling at PyPy.
00:18
<&Derakon>
Importing modules loads them into the local namespace, whatever that might be.
00:18
<@Tarinaky>
I meant the interpretter.
00:18
<&Derakon>
If you can do what you just suggested, then the implication is that any state anywhere in the program can be accessed.
00:18
<&Derakon>
Which would be a serious security breach.
00:19
<&Derakon>
I think Python's namespacing can probably be trusted~
00:19
<@Tarinaky>
I... don't...
00:19
<&Derakon>
Based on what logic?
00:20
<@Tarinaky>
Blatant tinfoil hat-ism.
00:20
<&Derakon>
How solid~
00:20
<@Tarinaky>
I did say blatant.
00:21
<&Derakon>
I'm just saying, I've never heard of Python's namespace rules being breached, especially not across module lines, and that strikes me as a serious security hole.
00:21
<&Derakon>
So if such a breach did exist, then a) I would expect to have heard about it, and b) I would expect it to have gotten patched quickly.
00:21 AverageJoe [evil1@Nightstar-dfmuir.ph.cox.net] has joined #code
00:21
<@Tarinaky>
I'm not sure how it's a serious security hole.
00:22
<&Derakon>
Any code anywhere in the program could access state anywhere else in the program.
00:22
<&Derakon>
I guess it does require getting an execution context.
00:22
<&Derakon>
But it's still super bad practice.
00:22
<@Tarinaky>
It does require modifying the source code of the program you're 'exploiting'.
00:22
<@Tarinaky>
Which is a pretty lame exploit.
00:22
<&Derakon>
Or getting access to a 'terp.
00:23 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: ]
00:23
<@Tarinaky>
I'm not sure if it applies to spawned child processes.
00:23
<@Tarinaky>
Indeed, it couldn't.
00:24
<@Tarinaky>
You'd need to be in the process with the code you want.
00:24
< AverageJoe>
tfw 3rd time installing the OS works without a hitch
00:24
< AverageJoe>
hold me
00:25
<@Tarinaky>
That's nothing. Earlier today I refactored a chunk of code with no unittest coverage and it worked first time.
00:25 Serah [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds]
00:25
< AverageJoe>
but last night i fucked up hard and nuked the partition table. all cuz i wanted winders 7 along side arch
00:25
< AverageJoe>
windows BEFORE linerx. srsly
00:26
<@Tarinaky>
You don't need to reinstall windows to fix that.
00:27
<@Tarinaky>
Err, reinstall linux
00:27
<@Tarinaky>
It's enough to just reinstall GRUB.
00:27
< AverageJoe>
i tried to recover, but it didnt work. i rly did
00:27 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code
00:27 mode/#code [+qo Vornicus Vornicus] by ChanServ
01:53 Turaiel is now known as Turaiel[Offline]
02:02
< simon>
hmm
02:03
< simon>
if I've got a grammar that yacc tells me has shift/reduce conflicts, this means that yacc's look-ahead(1) sets won't unambiguously tell me which production to use to derive.
02:04
< simon>
my professor calls this "non-deterministic behaviour" (and indeed, if I were to build a program with look-ahead(1) to solve this, I'd need to model non-determinism in terms of either back-tracking or computing all possible parses)
02:05
< simon>
but isn't this only non-deterministic with regards to the look-ahead size? are there grammars that are inevitably non-deterministic regardless of look-ahead size?
02:05
< simon>
i.e. grammars whose look-ahead, in order to achieve deterministic results, depends on the size of the input.
02:11 Turaiel[Offline] is now known as Turaiel
02:31 Turaiel is now known as Turaiel[Offline]
02:35
< simon>
so after some digging, I find out that what I'm thinking of is the set of unambiguous grammars that are not LR(k).
02:42 Turaiel[Offline] is now known as Turaiel
02:52 * Derakon puts together an extremely basic terrain tile fill script which just replicates the high-level maps at finer resolution.
03:51 Reivles [Reiver@Nightstar-4c3407ae.xtra.co.nz] has joined #code
03:54 VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down]
04:13 Kindamoody[zZz] is now known as Kindamoody
04:15
<&Derakon>
And now the rooms fill in with random platforms.
04:15
<&Derakon>
So that's progress.
04:24 mac [NSwebIRC@Nightstar-2dbe3d64.il.comcast.net] has joined #code
04:54
< Reivles>
Hey derakon
04:55
< Reivles>
Any updates?
05:02 celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
05:02
<&ToxicFrog>
"Hmm", sez I.
05:03
<&ToxicFrog>
"Intuitively, it seems like you should get 1.5 Arcane Combat procs per use of Flurry. But statistics is made of satan; I will calculate it."
05:03
<&ToxicFrog>
user=> (+ (* 1 0 (** 0.75 6)) (* 6 1 (** 0.75 5) 0.25) (* 15 2 (** 0.75 4) 0.25 0.25) (* 20 3 (** 0.75 3) (** 0.25 3)) (* 15 4 0.75 0.75 (** 0.25 4)) (* 6 5 0.75 (** 0.25 5)) (* 6 (** 0.25 6)))
05:03
<&ToxicFrog>
1.5
05:03
<&ToxicFrog>
Fuck statistics
05:05
<~Vornicus>
that's a big pile of math. ...are you doing the binomial distribution here?
05:06
<~Vornicus>
yeah, that's binomial distribution. Mean is always probability times trials.
05:10
<&ToxicFrog>
Goddamnit
05:10
<&ToxicFrog>
I should have just asked in here
05:12 mac [NSwebIRC@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: ]
05:13 Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code
05:27 ToxicFrog [ToxicFrog@Nightstar-gtjrvq.dsl.teksavvy.com] has quit [[NS] Quit: ZNC - http://znc.in]
05:33 ToxicFrog [ToxicFrog@Nightstar-gtjrvq.dsl.teksavvy.com] has joined #code
05:33 mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ
06:54 RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.]
06:57 RichyB [RichyB@Nightstar-c6u.vd5.170.83.IP] has joined #code
08:02 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [Connection closed]
08:25 Kindamoody is now known as Kindamoody|out
08:29 Turaiel is now known as Turaiel[Offline]
08:29 Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: BED]
08:38 Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code
08:46 * McMartin sleeps for several hours after gorging himself again.
08:46
<&McMartin>
I've kind of forgotten where I was in this Monocle stuff.
08:47 himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds]
08:48 himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code
08:48 mode/#code [+o himi] by ChanServ
08:58 himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds]
09:10 himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code
09:10 mode/#code [+o himi] by ChanServ
09:27 AverageJoe [evil1@Nightstar-dfmuir.ph.cox.net] has quit [[NS] Quit: Leaving]
10:09 himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds]
10:13 Orth [Reiver@Nightstar-4c3407ae.xtra.co.nz] has joined #code
10:14 Reivles [Reiver@Nightstar-4c3407ae.xtra.co.nz] has quit [Client closed the connection]
10:18 Orth [Reiver@Nightstar-4c3407ae.xtra.co.nz] has quit [Ping timeout: 121 seconds]
10:22 himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code
10:22 mode/#code [+o himi] by ChanServ
10:40 * McMartin instead creates working scrolly text in his C64 project.
11:02 Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has quit [Ping timeout: 121 seconds]
11:48
<&McMartin>
This demo is shippable, I think!
11:48
<&McMartin>
I've only got one more thing it would be neat if it could do, and I'm not sure if I care enough to do it.
11:52 Serah [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code
11:54 Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds]
12:31
<&jerith>
McMartin: So, I want to start wrapping stuff a little more sensibly in pymonocle.
12:31
<&jerith>
Oh, I should actually do that PR.
12:35
<&jerith>
McMartin: Which bits should I avoid wrapping for the moment?
12:39 VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code
13:01 ErikMesoy|sleep is now known as ErikMesoy
14:26 Serah [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds]
14:28 himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds]
14:41 himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code
14:41 mode/#code [+o himi] by ChanServ
14:59 Stalker [Z@Nightstar-ro94ms.balk.dk] has joined #code
15:31 himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds]
15:44 himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code
15:44 mode/#code [+o himi] by ChanServ
16:57 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code
16:57 mode/#code [+qo Vornicus Vornicus] by ChanServ
17:50 Kindamoody|out is now known as Kindamoody
17:54 celticminstrel [celticminst@Nightstar-gj43l1.dsl.bell.ca] has joined #code
17:54 mode/#code [+o celticminstrel] by ChanServ
19:31 Turaiel[Offline] is now known as Turaiel
20:34
<@Azash>
http://imgur.com/92ztcCd
20:37
< ErikMesoy>
nice
20:38
< ErikMesoy>
(I use named parameters for similar effect)
20:38 Kindamoody is now known as Kindamoody[zZz]
20:52
<&McMartin>
jerith: Sprites have become a fully opaque type now.
20:57
<&McMartin>
The part that will ultimately be work is going to be some kind of iterator, I think, but I'm still working out how best to do that in the C I have.
20:58
<&McMartin>
The function API part is easy, the stuff under the hood is trickier.
21:02
<&McMartin>
I guess that's really the main warning: pay more attention to functions than structs, because a lot of them are only exposed right now because I didn't have proper constructors for them.
21:03
<&McMartin>
No types *vanish* though, they just become opaque.
21:23
< ErikMesoy>
http://i.imgur.com/jacoj.jpg
21:51 Stalker [Z@Nightstar-ro94ms.balk.dk] has quit [Ping timeout: 121 seconds]
22:15 Stalker [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code
22:30 ErikMesoy is now known as ErikMesoy|sleep
23:28
<&McMartin>
Hrm, looking through it, I'm wondering if most of the mncl_raw API can be replaced with "just use struct"
23:29 PhiltheTechie [PhiltheTech@Nightstar-0iohse.supportituk.co.uk] has joined #code
23:30
< PhiltheTechie>
Evenin guys, Any javascript/jquery devs around?
23:30
<~Vornicus>
Just Ask Your Question
23:35 * Vornicus rebootinates
23:35 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has quit [[NS] Quit: ]
23:36
< PhiltheTechie>
Its a case of trying to make an animation as lean as possible. 50 divs animated moving randomly. You can see it at pbarton.co.uk/namethissite/results.php?term=&types=Video
23:37
< PhiltheTechie>
the animation is quite CPU heavy and i wondered if there was any other way to do this motion without 50 instances of the function running
23:39
< PhiltheTechie>
its a bit much to go into a jsfiddle sorry but the js is on a paste bin. one sec
23:39
<&McMartin>
I don't really do JS much, but the obvious alternate way to do it is to have one function that updates everything when called once
23:40 Vornicus [vorn@Nightstar-sn7kve.sd.cox.net] has joined #code
23:40 mode/#code [+qo Vornicus Vornicus] by ChanServ
23:40
< PhiltheTechie>
http://pastebin.com/ind8jatb
23:42
< PhiltheTechie>
would that actually reduce CPU load though if the function is the same to calc and animate?
23:44
<&McMartin>
It would depend on how much work it is for the browser to manage the timers; if it's a lot, then managing 1 timer might be noticably less than managing 50.
23:44
< PhiltheTechie>
thats true yeah, running only 1 timer
23:45
< PhiltheTechie>
ah no actually
23:45
<&McMartin>
(bear in mind I'm not an expert here; I've done one piece of JS animation ever)
23:45
< PhiltheTechie>
the timer is part of the .animate() function and is a speed variation
23:45
< PhiltheTechie>
so each one is different anyway to keep the divs independently moving
23:46
< PhiltheTechie>
no yeah i appreciate your input thanks!
23:46
<~Vornicus>
Wait, you're varying speed by changing the time it takes between animation ticks?
23:47
<&McMartin>
The part that was alarming to me was that it sounded like each animated element had its own timestep
23:48
< PhiltheTechie>
yeah so the function picks a random time to take for each animation
23:48
<&McMartin>
While this "works" in my notion of the JS model, where timers are managed by the browser and do their callbacks at will, my guess is that it won't scale very well
23:48
< PhiltheTechie>
thats just it, it all works quite smoothly but is CPU heavy
23:50
<~Vornicus>
I'd actually pick a single timestep, have each object decide where it wants to be and when it wants to be there and thus its per-time-step velocity and the timestep on which it needs to change.
23:54
<~Vornicus>
Which is to say, the video game way
23:55
< PhiltheTechie>
ive just been offered some advice on not using the jquery animate function as it uses a 'setInterval' timer to delay the animation
23:55
< PhiltheTechie>
and combined with this advice i think i know what to do
23:55
< PhiltheTechie>
just means writing a new animate function myself
23:56
<~Vornicus>
yeah. jquery's animate is set up for the case where there are few, completely independent, animations happening.
23:57
< PhiltheTechie>
booo. i prefer using ready made functions and the time i save can be used to smoke the finest green
23:57
< PhiltheTechie>
ah well
23:57
< PhiltheTechie>
back to the np++ for the night.
23:57
<~Vornicus>
Someone needs to learn to smoke and type at the same time then
23:58
< PhiltheTechie>
PC = indoors. GF = indoors. Weed = outside like a shamed child.
23:58
< PhiltheTechie>
:(
--- Log closed Sun Dec 01 00:00:21 2013
code logs -> 2013 -> Sat, 30 Nov 2013< code.20131129.log - code.20131201.log >

[ Latest log file ]