nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has joined #beagle
balrog has quit [Ping timeout: 240 seconds]
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
<vagrantc> /29/29
* vagrantc waves
<zmatt> you have 29 windows open?
<vagrantc> at least!
<set_> Hey! I am trying to do things!
<set_> Okay it goes.
<set_> As some of you know, I am trying to get involved more by making this wpan-next driver available in some context.
<set_> So, I need to learn zigbee standards, MAC (soft and hard), and then the WiFi standard.
<set_> I have a 5.15.x kernel installed right now and I am not seeing a lot of what is described in mailings and/or chat around "town."
<set_> 10:00! No. Dang it.
<set_> Can we make an exception this time b/c of my trying to understand how to assist w/ usb and zigbee standards?
<set_> is anyone else making this a reality right now?
buzzmarshall has quit [Quit: Konversation terminated!]
<set_> Could adding misc. constants in specific files be an effort?
vagrantc has quit [Quit: leaving]
balrog has joined #beagle
<set_> Is it too early?
<set_> GPIO and sysfs or configfs?
<set_> Dudes and Dudets, I just learned a simple way to read the UIO and other kernel docs. outside of man.
<set_> make pdfdocs && make htmldocs
<set_> Yes!
<set_> I feel free!
<set_> Hey...
<set_> when you guys say you are mainlining the .dts files, does it have to do w/ older .dts files not needing updating or changing?
<set_> I looked at, and it shows outdated things from three years ago or are they outdated?
<zmatt> who said what about mainlining which dts files?
<set_> Oh.
<set_> I thought rcn-ee said the people were trying to mainline the .dts files in the kernel.
<set_> For the am335x and am5729.
<zmatt> not sure what you mean, they already have dts files in the kernel
<set_> Hey @zmatt, since i have you here, what is the "die" calls in the source in that gpio lib you produced?
<set_> Oh.
<set_> Let me check.
<zmatt> just the simplest error handling function possible (print error message and exit)
<set_> Yep.
<set_> That one.
<set_> Oh.
<zmatt> obviously can be replaced by any other form of error handling if you prefer
<set_> Okay.
<set_> Can it be called something else outside of die?
<set_> For instance, mos?
<zmatt> if you also rename all uses of it you can call it whatever you fancy... why?
<set_> Oh. Okay. I was asking b/c die seems a bit morbid.
<zmatt> I mean, it kills the program
<set_> I was just reviewing the source. Oh! Now, I understand.
<set_> I thought it was for the readers.
<set_> Ha.
<set_> Well, now I know.
<set_> Is it like EOF and NULL?
<zmatt> none of these things are even remotely related?
<set_> Okay. You are right.
<set_> Sorry.
<set_> I keep reading that NULL in Linux is a black hole. It just gets erased for good.
<set_> And EOF, quits the program too, i.e. like the die() usage.
<set_> Just wondering. That is all.
<zmatt> it's just a simple form of handling errors that really shouldn't happen, in a way that's more useful than returning some error code that the caller is probably going to ignore because they don't know what to do with it either... as the old klingon proverb says, it's better to die() than to return() in failure ;-)
<set_> Aw!
<zmatt> you're confusing NULL (the pointer constant) with /dev/null (the device that discards anything written to it)
<set_> Aw. Yes.
<set_> You are right.
<zmatt> and EOF is just an abbreviation for "end of file", it does not imply any sort of behaviour
<set_> Oh. Okay.
<zmatt> and none of these things still anything to do with each other
<zmatt> *still have
<set_> Okay.
<set_> Hey @zmatt: none of those things have anything to do w/ one another. You are right.
<set_> But, they all are endings.
<zmatt> no they're not
<set_> Oh.
<set_> the /dev/null is the end of the file on the output unless specificity is called in the program.
<zmatt> ?????
<set_> For instance, if I was making atoi or atof work.
<zmatt> that sentence was really just a word-salad
<set_> in .c Sheesh.
<set_> So anyway.
<set_> Back to what I was saying.
<set_> Forget it.
<set_> atoi is ascii to int.
<set_> atof is ascii to float as in a double.
<set_> I have been goofin' around w/ stderr, stdin, stdout on the console.
<set_> I was learnin' about dprintf too!
<set_> Are using fd's a thing of the past?
<zmatt> that's a function you're very unlkely to have any use for
<zmatt> no
<set_> Okay. Good.
<set_> oh.
<set_> Why would I not use the dprintf function?
<zmatt> but normally you don't use the underlying file descriptors for stdin/stdout/stderr directly except in very specific circumstances
<set_> Aw. Okay. What are two "specific circumstances?"
<zmatt> because all other code uses printf()/fprintf(), and mixing that with dprintf will result in problems
<set_> Oh. Okay.
<set_> Hmm. I guess I better be careful.
<zmatt> basically, if there's an open FILE* for a file descriptor, you almost certainly want to use that instead of using the file descriptor directly (unless you know exactly what you're doing)
<zmatt> hence, use stdin/stdout/stderr instead of using the underlying file descriptors (0, 1, and 2 respectively) directly
<set_> Oh. Yep. Using has been teaching me some off topic instances.
<set_> You are right.
<set_> I was using specific commands to pipe and throw some info. from stdout to files.
<set_> and then into /dev/null and return it from nothingness.
<set_> Hey! Check this one out: . It shows the variable he made for '-c' to handle not ending the output.
<set_> I thought it was neat.
<set_> i.e. not ending the output on the commandline from the script runnin'.
<set_> The reason it is neat is b/c it hits errors but still runs.
nparafe has quit [Ping timeout: 256 seconds]
nparafe has joined #beagle
buzzmarshall has joined #beagle
vagrantc has joined #beagle
ikarso has joined #beagle
Shadyman has quit [Remote host closed the connection]
Shadyman has joined #beagle