#processbinder

[daniellcparts]

Tumblr Process Entry #1 3-16-17

Continuing on my experiment, I have been keeping track of two volunteers (friends) while they listen to a specific playlist of sounds and music for studying. The sounds/music on the playlist mimic auditory integration therapy and rhythmic auditory stimulation. These deal with attention deficit and Parkinson’s disease respectively. From just general feedback, the two volunteers have suggested a broader genre of music; however, in comparison to other music they have listened to, they personally believe they have a much better time focusing on work. Another test I am to try is a memory test while listening to music. 

[serenajcpsarts-blog]

Process Binder Check-In 4: This depicts my final research stages, and recent info I have found regarding the popular music types in America in order to predict the next fashion trend.  I have found various images and music styles, as well as songs for the final version of the video, which show the transformation of music and fashion over time.  

[mirandamcpsarts]

Over President’s Day weekend, I collected the bulk of my materials that I will use to complete my portrait. I’m excited to work with acrylic paints again after two years. I’m a little nervous that the Bristol paper will be too thin for the paper plate material I’m going to use for the shadow shapes. My plan is to mount the finished portrait on a larger canvas panel, on which I will add the Instagram features. 

[captainsafia]

How does the Node main process start?

OK! So in one of my previous blog posts, I tried to figure out how the Node main process is initialized. I ended up not being successful in that endeavor. As it turns out, the slide deck I was using as documentation to guide my code reading was a little out of date and referenced some parts of the code base that were moved. Thankfully, one of Node's maintainers (@Fishrock123) clarified this for me on Twitter and guided me towards the correct file. So now I know the right place to start!

As it turns out, src/node_main.cc is where it all starts. Let's dive into it!

cue dramatic music

If you're familiar with C/C++, then the structure of this file is pretty easy to grasp. The main function is the function that is automatically executed on program start by the compiler. The last line of this function lets us know that we are passing all our arguments and parameters to the node:Start function.

return node::Start(argc, argv);

I did some searching around the header and source files and found the definition of the node:Start function here. This function is not actually that big when you consider the number of lines of code it contains, but that's because it mostly invokes other functions that are responsible for bootstrapping the Node process. Here, let me explain what I mean. The first couple of lines in the function look like this.

atexit([] () { uv_tty_reset_mode(); }); PlatformInit(); node::performance::performance_node_start = PERFORMANCE_NOW();

The atexit bit drew my attention. I had seen this function used in other systems-level code but only had a vague idea as to what it did. Something about exit handling. I decided to do more research this time around and discovered that it was responsible for figuring out what to do when the current process exits. In this case, when the node process exits, the uv_tty_reset_mode function will be called. I didn't know what this function did. Although by now, I knew the fact that it had a uv prefix meant that it was related to libuv, the little async I/O library in some way. I did some digging in the documentation for libuv and found some details about it here. So basically, when you exit the Node process your TTY settings are also reset.

Side note: TTY stands for "TeleTYpewriter" and is a legacy carried from the Olden Days. Teletypewriters were peripherals that were used to connect to computer. Here is a picture of somebody using one. I always find these little terminology carry-overs from the early days of technology to be quite amusing. Naming things is hard so why think of new names for everything when you can just use the old one?

The next bit of code invokes the PlatformInit function. I saw a lot of comments around "file descriptors" and "signals." I'm not going to pretend to know what those things are now but I'm taking an Operating Systems course at the moment, so I might be able to speak about them more intelligently in the future! For now, I'm gonna say that this function is basically responsible for initializing some platform-dependent stuff. Good enough for me!

The next big function that is invoked is the Init function.

Init(&argc, const_cast<const char**>(argv), &exec_argc, &exec_argv);

From reading the code for the Init function, I discovered that is responsible for doing things like registering the built-in modules, passing the V8 configuration flags that the developer provides at the command line to V8, and configuring some other environment variables. The one function invocation that caught my attention here is this one.

node::RegisterBuiltinModules();

I think it would be interesting to figure out what goes on in here in further detail but I might do that at a later time. Don't wanna bite off more than I can chew!

Finally, the last few lines of code in this function are responsible for doing a lot of work related to V8.

V8::Initialize(); node::performance::performance_v8_start = PERFORMANCE_NOW(); v8_initialized = true; const int exit_code = Start(uv_default_loop(), argc, argv, exec_argc, exec_argv); if (trace_enabled) { v8_platform.StopTracingAgent(); } v8_initialized = false; V8::Dispose(); // uv_run cannot be called from the time before the beforeExit callback // runs until the program exits unless the event loop has any referenced // handles after beforeExit terminates. This prevents unrefed timers // that happen to terminate during shutdown from being run unsafely. // Since uv_run cannot be called, uv_async handles held by the platform // will never be fully cleaned up. v8_platform.Dispose();

So it looks like V8 is initialized, then a polymorphic definition of the Start function is invoked with the event loop passed through. Then there is some funny business going on with the tracing agent in V8.

Side note: If you try to Google "tracing agent" to learn more about tracing agents you will get a completely unexpected result. In other news, you can apparently hire an international manhunt team off the Internet. Isn't technology wonderful?

I did some more research about the tracing agent and found this rather helpful Wiki document. So it appears that tracing is a fairly new feature in V8. Essentially, this bit of code is responsible for configuring whatever custom code is necessary for the special logging that V8's tracer uses. That makes sense.

The next two lines were a little weird to me.

v8_initialized = false; V8::Dispose();

We just initialized the V8 interpreter but now we are setting it as initialized and disposing of it. Say what? To figure out what was going on here, I decided to head into the history of the code file and see when those changes had been introduced into the code base and found this commit from about 9 years ago. From the commit, it looks like the V8:Dispose line was actually added back into the code base after it was causing some errors with a particular test. This still didn't give me good insights into why it was being disposed, so I decided to figure out what the V8:Dispose function actually does.

I found some documentation that explained that V8:Dispose is responsible for releasing any resources that were used by V8. I'm starting to thing that what is going on here is the fact that the Node process actually gets cleaned up in the Start function. So the polymorphic Start function invoked here.

const int exit_code = Start(uv_default_loop(), argc, argv, exec_argc, exec_argv);

Runs until you exit from Node. At which point, you need to do all the cleanup of the V8 engine as well as halt the tracing agent used by V8. This makes sense. To validate this assumption, I would have to go in and read the code for the invoked Start function.

As usual, I leave my code read more confused and uninformed than when I started! There is actually a lot of places I can go from here. Despite only being about 50 lines of code (with comments and newlines), this function is giving me ideas for a lot of things I want to explore with the Node interpreter.

How are built-in modules loaded?

What exactly is PlatformInit doing? What's going on with all those file descriptors and signals?

What do all the polymorphic variations of the Start function do?

I'll try to pick these apart in other blog posts.

This whole process has been quite interesting. The C/C++ portion of this code base is rather gnarly. Especially for me, I've only ever utilized C/C++ in an academic context so reading this "industry-strength" code has been rather interesting.

It also goes to show that everyone maintaining Node is doing some truly rigorous and awesome technical work and that we should all love and praise them dearly!

[sophiescapstone]

First Lesson idea

 The image below: Mediterranean Landscape, 1953 by Pablo Picasso 

Students would identify and label 5 different angles in the art using a protractor.  Students would create their own geometric artwork with at least 5 different angles. 

4th grade Geometry 

CCSS: Draw and identify lines and angles, and classify shapes by properties of their lines and angles.  (This is the fourth grade geometry domain.)

CCSS.MATH.CONTENT.4.G.A.1 (This is the first standard under the domain.) Draw points, lines, line segments, rays, angles (right, acute, obtuse), and perpendicular and parallel lines. Identify these in two-dimensional figures.

Anchor Stnadard#7: Perceive and analyze artistic work. 

Anchor Standard#8: Interpret and meaning in artistic work. 

Anchor Standard#9: Apply criteria to evaluate artistic work.

Objectives:

SWBAT analyze both artistic and mathematic features in a painting, see art as both visual and mathematical, and create designs in their own artwork by measuring and drawing angles.

Identifiers: Students will identify angles in a picture. Students will measure angles with a protractor. Students will use angles to create their own art. 

[kemiacpsarts-blog]

Process Binder #2   3/3

So far, I’ve read 4 articles total, which is a bit short of where I wanted to be at this point into my project. But I haven’t had the time to properly balance working on my capstone project and doing long term assignments for my other class. Another challenge to my capstone project has been the fact that my computer’s charger stopped working. So I don’t have a working charger and now my computer has died. As a result, I’ve had to manage and allot my time carefully as I work in the library, since you can only borrow their laptops for four hours at a time. Four hours may sound like a lot. But *spoiler alert* it’s not. And as I wonder where the time went by, I constantly realize that I may have gotten a substantial amount of work done in many of my classes but haven’t even touched my capstone. In addition to technological issues, I have three midterms next week that I need to focus my attention on. I believe that after I’m done with my midterms, I can fully place my attention on finishing up the reading aspect of the project and move into organizing my thoughts into a coherent and cohesive literature review.

[alannarcpsarts-blog]

Recently, I have been practicing reading the book to get more comfortable for when I record the audio spoken word.  It has been challenging to read because listening back, I get self-conscious of the way my voice sounds.  I also find I am struggling with pace, and trying to read in a way that will encourage movement.  I feel this is one of the most difficult parts of my capstone because it is the foundation for the rest of the project.

[serenajcpsarts-blog]

Process Binder Check in #3. In this, you can find my research up to the 1980’s. In addition to this, there is the written feedback from my critical response feedback process. I will use this info for the rest of my project.

[serenajcpsarts-blog]

Learning Agreement 1

[mirandamcpsarts]

These are three preliminary sketches for my final capstone project that I completed over winter break. I like to start with basic ideas and get more detailed from there. I would like to do at least another 2 sketches to help me get a better understanding of how I will map out the large, abstract shadow shapes. 

[captainsafia]

Node module deep-dive: EventEmitter

So, I got pretty in the weeds with some C++ code in my last Node-related blog post and I figured I would get back into my comfort zone with some more JavaScript reading.

When I first started to learn Node, once of the things that I had trouble grasping was the event-driven nature of the language. I hadn't really interacted much with event-driven programming languages. Well, in hindsight, I guess I have. Prior to learning Node, I had used jQuery's .on and .click in my code, which is an event-driven programming style. At that point, it hadn't really hit me that I was writing event-driven code. Anyways, one of the things I've been curious to dive into for a while now is the event emitter in Node. So let's do that.

If you aren't familiar with Node's event-driven nature, there are a couple of blog posts you can check out that explain it much better than I can. Here's a few that might be helpful to you.

Understanding Node.js Event-Driven Architecture

event driven architecture node.js

Understanding the Node.js Event Loop

Events documentation in Node.js

OK! So I wanna read the code for the EventEmitter and see if I can grok what's going under the hood with the EventEmitter class. You can find the code that I am going to be referencing here.

So the two most critical functions in any EventEmitter object are the .on function and the .emit function. The .on function is the function that is responsible for listening to an event of a particular type. The .emit function is responsible for dispatching events of a particular type. I decided to start my exploration by diving into the code for these particular functions. I'm gonna start with .emit since it makes sense to see how events are emitted before looking at how they are listened to.

So the function declaration for emit is pretty self-explanatory if you've worked with EventEmitter objects. It takes in a type argument, which is usually a string, and a set of arguments that will be passed to the handler.

EventEmitter.prototype.emit = function emit(type, ...args) {

The first thing I noticed in this particular code is that "error"-type events and events of other types are handled differently. To be honest, it took me a while to grok what was happening exactly in the code below, especially the little if-else if bit. So basically, what this bit of code does is check to see if the event that is being emitted is an error. If it is, it checks to see if there is a listener for error events in the set of listeners attached to the EventEmitter. If there is a listener attached, the function returns

let doError = (type === 'error'); const events = this._events; if (events !== undefined) doError = (doError && events.error === undefined); else if (!doError) return false;

If there is no event listener (as the comment states), then the emitter will throw an error to the user.

// If there is no 'error' event listener then throw. if (doError) { let er; if (args.length > 0) er = args[0]; if (er instanceof Error) { throw er; // Unhandled 'error' event } // At least give some kind of context to the user const errors = lazyErrors(); const err = new errors.Error('ERR_UNHANDLED_ERROR', er); err.context = er; throw err; }

On the other hand, if the type that is being thrown is not an error, then the emit function will look through the listeners attached on the EventEmitter object to see if any listeners have been declared for that particular type and invoke them.

const handler = events[type]; if (handler === undefined) return false; if (typeof handler === 'function') { Reflect.apply(handler, this, args); } else { const len = handler.length; const listeners = arrayClone(handler, len); for (var i = 0; i < len; ++i) Reflect.apply(listeners[i], this, args); } return true;

Neat-o! That was pretty straightforward. On to the on function...

The on function in the EventEmitter implicitly invokes the _addListener internal function which is defined with a declaration as follows.

function _addListener(target, type, listener, prepend)

Most of these parameters are self-explanatory, the only curious one for me was the prepend parameter. As it turns out, this parameter defaults to false and is not configurable by the developer through any public APIs.

Side note: Just kidding! I came across some GitHub commit messages that cleared this up. It appears that it is set to false in the _addListener object because a lot of developers were inappropriately accessing the internal _events attribute on the EventEmitter object to add listeners to the beginning of the list. If you want to do this, you should use prependListener.

The _addListener function starts off by doing some basic parameter-validation. We don't want anyone to shoot themselves in the foot! Once the parameters have been added, the function attempts to add the listener for type to the events attribute on the current EventEmitter object. One of the bits of code that I found interesting was the code below.

if (events === undefined) { events = target._events = Object.create(null); target._eventsCount = 0; } else { // To avoid recursion in the case that type === "newListener"! Before // adding it to the listeners, first emit "newListener". if (events.newListener !== undefined) { target.emit('newListener', type, listener.listener ? listener.listener : listener); // Re-assign `events` because a newListener handler could have caused the // this._events to be assigned to a new object events = target._events; } existing = events[type]; }

I'm particularly curious about the else here. So it looks like if the events attribute has already been initialized on the current EventEmitter object (meaning that we've already added a listener before), there is some funky edge-case checking business going on. I decided to do some GitHub anthropology to figure out when this particular code change had been added to get some more context into how the bug emerged and why it was added. I quickly realized this was a bad idea because this particular bit of logic has been in the code for about 4 years and I had trouble tracking down when it originated. I tried to read the code more closely to see what type of edge case this was checking for exactly.

I eventually figured it out not by reading code, but by reading documentation. Don't forget to eat your vegetables and read all the docs, kids! The Node documentation states:

All EventEmitters emit the event 'newListener' when new listeners are added and 'removeListener' when existing listeners are removed.

So basically, the newListener event is emitted when a new listener is added before the actually listener is added to the _events attribute on the EventEmitter. This is the case because if you are adding a newListener event listener and it is added to the list of events before newListener is emitted by default then it will end up invoking itself. This is why this newListener emit code is placed at the top of the function.

The next bit of code tries to figure out whether a listener for this type has already been attached. Basically, what this is doing is making sure that if there is only one listener for an event then it is set as a function value in the _events associative array. If they are more than one listeners, it is set as an array. It is a minor optimizations, but many minor optimizations are what make Node great!

if (existing === undefined) { // Optimize the case of one listener. Don't need the extra array object. existing = events[type] = listener; ++target._eventsCount; } else { if (typeof existing === 'function') { // Adding the second element, need to change to array. existing = events[type] = prepend ? [listener, existing] : [existing, listener]; // If we've already got an array, just append. } else if (prepend) { existing.unshift(listener); } else { existing.push(listener); }

The last check made in this function tries to confirm whether or not there were too many listeners attached on a particular event emitter for a particular event type. If this is the case, it might mean that there is an error in the code. In general, I don't think it is good practice to have many listeners attached to a single event so Node does some helpful checking to warn you if you are doing this.

// Check for listener leak if (!existing.warned) { m = $getMaxListeners(target); if (m && m > 0 && existing.length > m) { existing.warned = true; // No error code for this since it is a Warning const w = new Error('Possible EventEmitter memory leak detected. ' + `${existing.length} ${String(type)} listeners ` + 'added. Use emitter.setMaxListeners() to ' + 'increase limit'); w.name = 'MaxListenersExceededWarning'; w.emitter = target; w.type = type; w.count = existing.length; process.emitWarning(w); } } }

And that's it! At the end of all this, this .on function returns the EventEmitter object it is attached to.

I really liked reading the code for the EventEmitter. I found that it was very clear and approachable (unlike the C++ adventure I went on last time) — although I suspect this has to do a fair bit with my familiarity with the language.

[serenajcpsarts-blog]

In completing my process binder, I have chosen to show slides from my final video which show one example of how I portrayed one decade of music, fashion, and my explanation of the relationship between the two, as seen in the images.  I also included my introductory page.  The final video was so rewarding and I am so satisfied with my final product.  I also included my graph which allowed me to find the most popular modern music, as well as the slide which finally depicted my final sketches which I showed during the video! I am very proud of my work on this project and hope I can use this information for future endeavors.  

[mirandamcpsarts]

I made a new, larger sketch to help me get a better idea of the shadow shapes I will create for the final product. My sketch started off with more detailed shadow shapes, but as I progressed I made a conscious effort to draw the shapes bigger and more block-y so that they can be easier to manipulate for the final portrait. I will continue to work on making larger, easier-to-work-with shadow shapes. Also, since I intend to apply the interchangeable shadow shapes only to the face, I might make the hair and clothing more delicate and expressionist. 

The process of offering and receiving feedback one-on-one with Anna was incredibly insightful but also oddly nerve-wracking. It’s hard to give advice on a work that is personal to you. Anna recommended that when I go about creating the final portrait, I should trace the shadow shapes so that the process becomes more like an assembly line. I learned that the larger the shadow shapes, the easier assembly will be for me. Also, it will make it easier for the viewer to interact with the piece. 

[kemiacpsarts-blog]

Process Binder #1 2/14

I don’t know where to start. For the past week, I’ve read three journal articles on high-stakes testing and arts education and had an advising meeting with Harold for my project, which is probably the most time that I’ve spent working on my review so far. I wish I had more time to work on my capstone, but I’m still trying to figure out how to fit it into my schedule. I’ve found valuable information in the articles that I’ve read this week. I wasn’t so fond of the first article that I read “Seismic Shifts in the Education Landscape: What Do They Mean for Arts Education and Arts Education Policy” by F. Sabol. It was a pretty well written article, but I didn’t find too much information that was pertinent to the discourse that I was trying to create amongst the articles. The article felt like it was jumping from one idea to another idea, instead of focusing on one big idea. However, the article serves as an overview of drastic changes being made in Arts Education and the policy realm. In addition, the article did help me see how the common core is working alongside other educational issues such as funding cuts. So perhaps, when I’m crafting my review, I may create a subsection that discusses what scholars are saying about the common core in relation to other educational problems. I thought that the second article brought an interesting perspective in the sense that it wasn’t being especially critical of the nature of high-stakes testing. Robert Baker Jr in “The Effects of High-Stakes Testing Policy on Arts Education. Arts Education Policy Review” mentions that Louisiana public schools are waiving arts education to students who are scoring basic on the standardized tests. He details, however, that there is empirical evidence that points to students scoring higher test scores when they are enrolled in visual and music arts classes compared to students who are not enrolled in these classes. There appears to be a lot of literature that shows how arts education is forsaken in order to make room for more standardized testing or focus on math and English. Finally, my third article “From Dewey to No Child Left Behind: The Evolution and Devolution of Public Arts Education” illustrates the history and the historic attitude towards arts education and the current day trends of arts education. Moreover, the article looks into the Texas state government and legislature in relation to policy that were made towards arts education. From the articles that I’ve read so far, I’ve noticed that there has been a focus on Southern school districts, so I wonder if there is a gap in literature based on the regions that were highlighted. If so, then that would serve as another section to write about in my review. I’ve gathered valuable information from these articles and have noticed a few themes and patterns weaved in. So I hope to read 3 more articles next week and reflect on the type of literature that is out there.