p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

vapid cutlery

Apr 17, 2007

php:

<?
"it's george costanza" ?>

MononcQc posted:

general vs. domain specific. ain't no debugging that's as simple and universal as printing text.

also some languages do better with tracing than debuggers, especially languages used in time sensitive or distributed/parallel/concurrent scenarios, where debuggers are enough to gently caress things up and make things worse.

if that's really an excuse why don't the tools for those language use something like time travel tracing where you can record execution for an entire program and step through it later in a debugger

# ? Sep 7, 2012 05:14

Adbot: ADBOT LOVES YOU

# ? May 8, 2024 13:12

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

tef posted:

i think i've seen enough php rants

ahahaha that isn't just a google personalisation thing, it actually does that all the time. awesome.

# ? Sep 7, 2012 10:21

qntm: Jun 17, 2009

Gazpacho posted:

my dad sent me a link to a php job yesterday, told him i looked at it + a brief rant about PHP including T_PAMAAYIM_NEKEUDATOYIM

e: i'll post the rant if anyones interested

PHP rants are a solved problem at this point

# ? Sep 7, 2012 11:15

MononcQc: May 29, 2007

vapid cutlery posted:

if that's really an excuse why don't the tools for those language use something like time travel tracing where you can record execution for an entire program and step through it later in a debugger

A few reasons I can think of.

Allowing to do step-by-step execution in the debugger would imply that all the state, over the life of the program, has been saved through traces. While normal debuggers will not need to hold much more state or memory than the program would at any point in time, tracing would quickly blow it up. If you mutate 10mb of memory per second and run the program for a minute, that's 600mb of data you need to store for the trace. Tracing live is usually simpler.
Tracing will often end up centralizing trace data, queuing it up. Parallel operations will not be possible to inspect in the order they happened, but in the order they were perceived by the tracer(s).
Tracing everything in a system can slow it down quite a bit and impact the program itself, ruining the whole point. It's often desired to trace only a part of the live system, and a subset of all the events (tracing GC, forking, calls, messages, independently

There's still interesting work being done in that area. I'm not aware of what all other languages are doing, but spending a lot of time in Erlang, from time to time, a few interesting tools pop up.

One of them is erlubi, written by Kresten Krab Thorup (guy who worked at NeXT, wrote the GNU Objective-C runtime, worked on added generics to Java, now working with Erlang), which allows to trace processes live, in 3D:

https://www.youtube.com/watch?v=lHoWfeNuAN8

There's definitely interesting stuff to be done with tracing, especially when you can trace across server boundaries.

# ? Sep 7, 2012 12:49

tef: May 30, 2004; -> some l-system crap ->

Mr Dog posted:

what's the difference between a programming language and a DSL/toy language

a programming language has a debugger

god loving help you if you have to debug a toy language (i.e. use a toy language)

I hate to go all teapot, but I've found debuggers the most useful on code I didn't write myself. On the other hand, decent logging has been wonderful for production post-mortems.

# ? Sep 7, 2012 14:42

tef: May 30, 2004; -> some l-system crap ->

everything is terrible brb writing my own hardware, kernel, virtual machine, compiler, linker, docs, editor, drivers

# ? Sep 7, 2012 14:50

gabensraum: Sep 16, 2003; LOAD "NICE!",8,1

Jonnty posted:

ahahaha that isn't just a google personalisation thing, it actually does that all the time. awesome.

was intrigued so i gave it a go

tef posted:

everything is terrible brb writing my own hardware, kernel, virtual machine, compiler, linker, docs, editor, drivers

don't worry about the docs

# ? Sep 7, 2012 15:54

Sapozhnik: Jan 2, 2005; Nap Ghost

deep square leg posted:

php is the nickelback of programming languages

lol

Also I wish I had the luxury of only debugging code I wrote myself. The only other toy programming language I've ever had the honour of dealing with basically consisted of some extensions to Excel where methods from COM type libraries show up as Excel functions (this is how I learned that registering a function with Excel is an O(n) operation), expressions transitively depending on a "variable" become lambdas that can then be evaluated using the "eval" function, and any string of a particular (admittedly unlikely) form is interpreted as an interned pointer. I also remember lots of heap fragmentation, claustrophobia within a 2GB address space, and lots of crying.

But it's ok because it makes it easier for non-programmers to develop things, you see.

Logging is nice and I totes make use of it where I can, but it can be problematic from interrupt handlers (you can usually get away with sending an exclamation mark out of a spare UART or something). Then again lol @ trying to debug interrupt handlers with a debugger.

# ? Sep 7, 2012 17:00

JawnV6: Jul 4, 2004; So hot ...

MononcQc posted:

Tracing will often end up centralizing trace data, queuing it up. Parallel operations will not be possible to inspect in the order they happened, but in the order they were perceived by the tracer(s).

is this an irl problem s/w people have

# ? Sep 7, 2012 17:45

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

JawnV6 posted:

is this an irl problem s/w people have

not me but i dont write interesting software

# ? Sep 7, 2012 17:49

Sneaking Mission: Nov 11, 2008

just process things one by one what's the loving rush?

# ? Sep 7, 2012 17:51

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

people are in too much of a hurry these days. they should slow down and learn to take life at a more relaxed pace.

# ? Sep 7, 2012 17:57

MononcQc: May 29, 2007

JawnV6 posted:

is this an irl problem s/w people have

Very rarely. It's a problem you generally have when you don't understand the nature of parallel/concurrent software and you do expect a universal correct ordering of events all the time instead of on synchronization points.

I'm pretty sure someone writing a debugger related to that will get a poo poo ton of bug reports just because of that. "but it's supposed to happen at the same time and the trace-based logger says there's a time difference!" etc.

# ? Sep 7, 2012 18:10

JawnV6: Jul 4, 2004; So hot ...

im just confused why you can't use timestamps or something to correlate

# ? Sep 7, 2012 18:20

MononcQc: May 29, 2007

JawnV6 posted:

im just confused why you can't use timestamps or something to correlate

well, that depends whether your trace systems timestamps on generation or on reception by the piece of code that does the tracing in parallel systems (and where it resides). It's easy to do both ways on a single core/thread, and the tracer timestamping may mess up the ordering when going multicore.

If you go distributed, timestamps are garbage and unreliable and if you rely on timestamps only for global ordering of events at any kind of high precision, you're in for a world of trouble. In that case what you want are Lamport Clocks and derivatives, which again are not especially super reliable in all cases for tracing, but provide a great relative time system to put some ordering in place.

My view of things is influenced by distributed tracing systems because those I tend to use were built with distribution in mind. But you're totally right that you can ignore the issue (mostly) by having whatever trace system you have timestamp everything on its own and be right pretty much all the time.

# ? Sep 7, 2012 18:44

JawnV6: Jul 4, 2004; So hot ...

distributed?

you mean like... cores that are a few thousand nm's away right??

# ? Sep 7, 2012 18:50

MononcQc: May 29, 2007

JawnV6 posted:

distributed?

you mean like... cores that are a few thousand nm's away right??

I mean tracing programs that run on different computers or servers, as part of a single distributed system. Many milliseconds away.

# ? Sep 7, 2012 18:57

JawnV6: Jul 4, 2004; So hot ...

a billion+ cycles? :aaaaa:

# ? Sep 7, 2012 19:02

Max Facetime: Apr 18, 2009

here's some more from the top of my head

- the time between changing something and logging the change can vary, think context switches
- one windows api for measuring time has 1ms resolution but ~15ms precision, this can be upped to 1ms precision when needed but it's a system-wide change
- queryperformancecounter has a much better precision but it's harder to turn into a proper timestamp
- different cores might run at slightly different speeds, causing measurements to drift

# ? Sep 7, 2012 19:30

ChiralCondensate: Nov 13, 2007; what is that man doing to his colour palette?; Grimey Drawer

JawnV6 posted:

im just confused why you can't use timestamps or something to correlate

JawnV6 posted:

distributed?

you mean like... cores that are a few thousand nm's away right??

just use the correlation effect, it's not like there's any physical restriction on the distance over which it can work

# ? Sep 7, 2012 19:35

MononcQc: May 29, 2007

JawnV6 posted:

a billion+ cycles?

Well yeah. I can trace on many Erlang nodes at once, for example, and trace GCs, messages sent, function calls, etc.

code:

(<7713.98.0>) {echo,b@ferdmbp} ! {<7713.98.0>,hello} (Timestamp: {1347,42406,16267})
(<7713.98.0>) << hello (Timestamp: {1347,42406,16938})
(<7713.98.0>) in {timer,sleep,1} (Timestamp: {1347,42406,16945})
(<7713.98.0>) out {timer,sleep,1} (Timestamp: {1347,42406,16952})
(<7932.127.0>) << {<7713.98.0>,hello} (Timestamp: {1347,42406,16604})
(<7932.127.0>) <7713.98.0> ! hello (Timestamp: {1347,42406,16711})
(<7713.98.0>) << timeout (Timestamp: {1347,42407,17113})
(<7713.98.0>) exit normal (Timestamp: {1347,42407,17118})

The above for example, is tracing the communication of two processes across nodes A and B (7713 and 7932) from a node C. It traces function calls, state of processes, etc.
You can see the first process (<7713.98.0>) calling the ! operator, then sending a message (<< hello) to the other node. The process then goes to sleep (on my demand, bu entering the timer:sleep/1 function).

Then the second process on the other node receives the message (<< {<7713.98.0>,hello}), which contains the return address of the sending process. The process replies with 'hello'.

Then you can see the first process timing out (having nothing to do anymore), then being cleaned up (exit normal).

The trace events all contain a timestamp ({MegaSec, Secs, MicroSecs}), and more events such as GC can be traced, giving results like:

code:

(<7932.127.0>) gc_start [{old_heap_block_size,0},
 {heap_block_size,377},
 {mbuf_size,0},
 {recent_size,0},
 {stack_size,28},
 {old_heap_size,0},
 {heap_size,346},
 {bin_vheap_size,0},
 {bin_vheap_block_size,46368},
 {bin_old_vheap_size,0},
 {bin_old_vheap_block_size,46368}] (Timestamp: {1347,42406,16637})
(<7932.127.0>) gc_end [{old_heap_block_size,0},
 {heap_block_size,377},
 {mbuf_size,0},
 {recent_size,161},
 {stack_size,28},
 {old_heap_size,0},
 {heap_size,161},
 {bin_vheap_size,0},
 {bin_vheap_block_size,46368},
 {bin_old_vheap_size,0},
 {bin_old_vheap_block_size,46368}] (Timestamp: {1347,42406,16661})

Which shows data regarding to the GC. Note that all terms are Erlang-readable, so programs can trace themselves at run-time and react to these traces. This is all free, coming out of the box, and you can also send the trace output to sockets or file descriptors to dump things the way you want.

Also note that this is different from syscall tracing with tools like DTrace, which is also available, but as a different system.

EDIT: timestamps have microsec resolution, not millisec.
EDIT2: this is traced used a tool call 'dbg' that any Erlang node can use, but the VM comes with 2-3 other similar tools with different use cases in mind. The whole stack is traceable as gently caress.
EDIT3: GC is per-process, not per-VM, and fully concurrent, hence why it includes process identifier in the reports.

MononcQc fucked around with this message at 19:43 on Sep 7, 2012

# ? Sep 7, 2012 19:36

MononcQc: May 29, 2007

Win8 Hetro Experie posted:

here's some more from the top of my head

- the time between changing something and logging the change can vary, think context switches
- one windows api for measuring time has 1ms resolution but ~15ms precision, this can be upped to 1ms precision when needed but it's a system-wide change
- queryperformancecounter has a much better precision but it's harder to turn into a proper timestamp
- different cores might run at slightly different speeds, causing measurements to drift

Those are all good. I once had a problem with logs where the logs were split and moved after each hour, and our requests lasting ~1ms would sometimes gently caress up by hour change

The log would have a timestamp, and so would the event that it noted (the event had its own timestamp to compare). At some point, our log analysis platform freaked out because a certain log entry was timestamped in the hour before the event it contained happened.

The issue was that the logged event had its initial timestamp, and changed cores at some point after noting its timestamp and being logged (less than 2ms apart or something). The logging process on the new core had its clock a tiny bit before the original process the event was on, and it happened right on the hour change.

Even on a single server, timestamps can have very weird ways to mess with you. It was fun debugging that one.

# ? Sep 7, 2012 19:48

Zombywuf: Mar 29, 2008

tef posted:

everything is terrible brb writing my own hardware, kernel, virtual machine, compiler, linker, docs, editor, drivers

Jenkins has driven me over the edge so I'm now writing my own build server.

# ? Sep 7, 2012 20:27

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Zombywuf posted:

Jenkins has driven me over the edge so I'm now writing my own build server.

what's wrong w/ jenkins?

# ? Sep 7, 2012 20:35

Sapozhnik: Jan 2, 2005; Nap Ghost

tef posted:

everything is terrible brb writing my own hardware, kernel, virtual machine, compiler, linker, docs, editor, drivers

have you considered using Forth?

# ? Sep 7, 2012 20:44

MononcQc: May 29, 2007

Forth owns.

# ? Sep 7, 2012 20:56

GameCube: Nov 21, 2006

trex eaterofcadrs posted:

what's wrong w/ jenkins?

it's terrible

# ? Sep 7, 2012 20:58

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Werthog posted:

it's terrible

let's not beat around the bush here, all software is terrible, but as far as CI goes jenkins isn't the worst by a long shot

# ? Sep 7, 2012 21:11

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

jenkins seems mostly ok, it's liek the bugzilla of build servers. poo poo works mostly but ugh just look at it

# ? Sep 7, 2012 21:30

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

trex eaterofcadrs posted:

let's not beat around the bush here, all software is terrible, but as far as CI goes jenkins isn't the worst by a long shot

cruisecontrol is the worst i've used

jenkins is confusing but it works and we have irc notifications so it's not like i have to log in on a regular basis

# ? Sep 7, 2012 21:49

JawnV6: Jul 4, 2004; So hot ...

tef posted:

everything is terrible brb writing my own hardware, kernel, virtual machine, compiler, linker, docs, editor, drivers

every time i have this thought, God says...

# ? Sep 7, 2012 22:19

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

JawnV6 posted:

every time i have this thought, God says...

at least write a compiler for fun

# ? Sep 7, 2012 22:21

JawnV6: Jul 4, 2004; So hot ...

MononcQc posted:

EDIT: timestamps have microsec resolution, not millisec.
EDIT2: this is traced used a tool call 'dbg' that any Erlang node can use, but the VM comes with 2-3 other similar tools with different use cases in mind. The whole stack is traceable as gently caress.
EDIT3: GC is per-process, not per-VM, and fully concurrent, hence why it includes process identifier in the reports.

this was really informative, thanks

we have enough Big Issues way down at my level, nice to know if we ever knock those out there's enough interesting work way up there with y'all

# ? Sep 7, 2012 22:22

JawnV6: Jul 4, 2004; So hot ...

Cocoa Crispies posted:

at least write a compiler for fun

i took a class and built one so i'm familiar enough with the flex/yacc stack , i could probably knock another out but I don't really have the 'itch' to write one just yet

# ? Sep 7, 2012 22:24

TiMBuS: Sep 25, 2007; LOL WUT?

tef posted:

really i'd just like traits over class inheritance easily, and mutable at runtime.

yes yes moose yes

ps. if someone tells you the answer is 'perl6' what they mean to say is 'go gently caress yourself'

well, i sure would like to watch you code some perl 6 :q:

# ? Sep 8, 2012 00:23

TiMBuS: Sep 25, 2007; LOL WUT?

wait since moose is just perl 5's port of perl 6 oo, dose that mean perl coders are all loving themselves??
perhaps you mean it in a good way?

# ? Sep 8, 2012 00:26

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

i have to actually write a "compiler" soon, im not looking forward to it.

edit: a "compiler" in the loose sense that it transforms one language to another

# ? Sep 8, 2012 01:10