| June 21, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Office |
2.00 HR |
|
Coordination and email Communications with Sensorica affiliates, answering Contract us list.
|
|
|
| June 21, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Manual |
4.00 HR |
|
Continued to work at the lab, preparing for moving the lab. Met with Evelyne who took the Matrioshka at her locale, and continues the cleanup and preparations.
|
|
|
| June 20, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Manual |
8.00 HR |
|
worked at the lab, arranging for lab moving, cleaning, discard non-usefull material
|
|
|
| June 19, 2018 |
Time Contribution |
Tibi |
Infrastructure-virtual |
Work - Meeting |
2.00 HR |
Open
|
Meeting with Tim on Next Generation NRP. Discussed steps forward, convergence
|
|
|
| June 14, 2018 |
Time Contribution |
Tibi |
Verdun |
Work - Meeting |
0.75 HR |
|
Phone call with David, discussing about funding, where to take this next.
|
|
|
| June 7, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Meeting |
1.50 HR |
|
Meeting with Tim, discussing mostly about Consultancy services development, where we are, where to go next, reassessment of priorities...
|
|
|
| June 5, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Meeting |
1.00 HR |
|
Meeting with Tim, and Charles. Touching base on important things after my EC contract deep dive.
|
|
|
| June 4, 2018 |
Time Contribution |
Tibi |
2D strain transducer |
Work - Meeting |
1.00 HR |
|
Preparation and meeting with David, discuss how project should move forward
|
|
|
| June 4, 2018 |
Time Contribution |
Tibi |
Soccer amateur |
Work - Administration |
0.50 HR |
|
Exchange with Stephane, from Ville de Montreal, about application of the project here in Montreal.
|
|
|
| June 4, 2018 |
Time Contribution |
Tibi |
Verdun |
Work - Administration |
0.50 HR |
|
PME Montreal send us possible locations for the first lab. I documented, sent signals to PierreLaurent and Eimen about it.
|
|
|
| May 22, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
1.62 HR |
|
Checking out the create order UI. Looks pretty good; might want to make the description row-fluid to get it to sit to the right on monitors and go under the thumbnail on mobile. Also, I thought I had the controls to the right of the thumbnail, which would make the description on the bottom make more sense. Looking into that. The template overrides the extra_head block without adding the block.super, so I stuck that in. Probably should consider this first if there are any other silly looking things in the HTML. Perfect.
Now for the finale, testing the value equations UI. Made a roughly fair value equation that rewards squeezing work. I'm now double-billing for coding and squeezing lemons (for the lemonade stand test project). Have to make a juicer to complete the process, can't find the control to adjust the quantity. So I went to add an unplanned output to the process as a quick hack, but I found that the dialog has a lot of goofy text that doesn't really belong anywhere. Investigating. Went ahead and added block.super since it was missing. The type variable wasn't declared, which really should have caused it to crash, but didn't. Should work now.
The resource type dropdown list options are not quite right; may be due to the missing label fields. Should be easier to fix at the tag level, otherwise will need to sweep all the templates. Alternatively, it might be due to a missing process pattern or a lack of output resource types (though I don't see how they would get messed up in this way). It actually looks as if it's the string-ification of resource types adding a list of facet values, since two forms that have nothing at all else in common are having the same problem. Er, it looks like the facets were included intentionally. Anyway, the labels are fixed.
Looks like everything works to me. Calling it a day on this one, switching over to brainstorming on the next-gen NRP standardization minimal requirements.
|
Create new classical NRP for the Vedun project
|
|
| May 22, 2018 |
Time Contribution |
davidh |
Infrastructure-virtual |
Work - Writing |
2.00 HR |
|
Developed a first draft of requirements for a hypothetical inter-network standardization project. Added it to the Next-Gen NRP doc.
|
Budget for next p2p generation IT infrastructure
|
|
| May 22, 2018 |
Time Contribution |
Tibi |
Verdun |
Work - Administration |
0.50 HR |
Open
|
Updated Trello board
|
|
|
| May 22, 2018 |
Time Contribution |
Tibi |
Infrastructure-virtual |
Work - Infrastructure - OVNi module development |
0.50 HR |
Open
|
dcoumented some new ideas in the next gen NRP doc, communicated a bit with some sensoricans about my activities.
|
|
|
| May 22, 2018 |
Time Contribution |
Tibi |
Verdun |
Work - Administration |
0.50 HR |
Open
|
Added some new items to the planning doc for the Verdun project, while reading proposals.
|
|
|
| May 21, 2018 |
Time Contribution |
Tibi |
Building SENSORICA |
Work - Business building |
2.75 HR |
Open
|
Communication with Tim about recycling initiative, setting up a doc, writing initial content, adding methodology and customizing it for this context, communicated with others, sent to david Lametti, Ville de Montreal and Stephane from Ville Intelligeante.
|
|
|
| May 21, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
1.42 HR |
|
Investigating the 2 remaining create_order test fails. In both cases, the offending commitment list is from changeable.producing_commitments(), which should have two elements, but instead has none. Indeed, the list of commitments makes no mention of changeable. Will have to examine the test system to make sure there really should be changeables involved, as I only see the order for parent, child, or grandchild, and my impression was that those are related only to each other.
Sure enough, there are no solid links between those 2 systems that I can find, so I don't know how this was supposed to happen.
Changed them to order the workflow recipe RTs, and everything now works. Confetti please.
And now the server is handing out 500 internal server errors. Will have to check out log files. Yeah that one is going to be webfaction's problem, unfortunately.
|
Create new classical NRP for the Vedun project
|
|
| May 21, 2018 |
Time Contribution |
Tibi |
Verdun |
Work - Administration |
0.75 HR |
Open
|
Propagated Emian's urban analysis document, for chosing the place for the 5 CELLs, sent it to PME Montreal, Ville de Montreal (Development economique) and David.
|
|
|
| May 20, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
3.80 HR |
|
Messing with the test_orders.py; the field names have changed, the primary keys have changed, and the tests relied on all of that. Luckily I did figure out what the old primary keys were.
Er, can't import django.forms.BaseFormSet? I'm looking at the source right now.....
Can't import it. Interesting. aha, it's django.forms.formsets.BaseFormSet
If this doesn't work I need to create an OrderItem model class to bind to the form class; they could be confused that they aren't really associated with real live commitments in an exact way.
Needs a max_items to survive, eh? Added all the static fields I could see the Django code doing to its own formsets.
Looks like the #510 fix test passes, but I've spoken too soon about that before.
Drat. The RT IDs are still not appearing.
Just for fun, try getting rid of the boundness to Commitment, which I don't like at all anyway. Maybe it will validate anyway.
That worked. I need to stop trusting the Django documentation.
Came up with a hackish, inelegant fix that works for the IDs, plugged default values of zero in literally every place conceivable for the quantities, since they went unfilled in the initializers. Seems to make the forms' is_valid work, finally. Now, to deal with the 2 remaining failing tests (yeah we're down two!)
|
Create new classical NRP for the Vedun project
|
|
| May 18, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
5.22 HR |
|
About to get a smoking gun in relation to VerdunNRP #10 and valnet #510. It's the order item form. It can't find its fields right. Or maybe my list comprehension sucked. Both of these things are true.
Probably going to need to rewrite the form class as an order form with an order item form formset. Otherwise I'm just not equipped to figure out what is confusing the form bindings.
The plan is like this. I wanted to mess with the order form anyway, get rid of the table, make it look more like the inventory list, make things a little more sensible with regard to the fact that it isn't bound to a commitment object anyway, it doesn't use half of its fields now, etc. etc. I can clean it up so that it uses an independent template. Done with that template, _order_item_rt.html
Now for the parent template, create_order.html
Done (it has some TODOs for filtering, but I doubt it will come up)
Made some changes to forms.OrderItemForm, made forms.OrderItemFormSet to manage them
Modified the view to accommodate.
Won't have time to test it, so I leave it down for today.
|
Create new classical NRP for the Vedun project
|
|
| May 17, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
0.92 HR |
|
Apparently there was a problem saving the notes from my last debug session, so the last line should have read:
The fail-early scenario (implemented in views.create_order) was the one that played out, so the form classes are a good place to start. E.g. which of the form validators flunked, or was it the additional stipulation that there needed to be at least one non-zero order item?
In all 3 cases, the receiver was being problematic; it doesn't have a default even when the list is populated. Added defaults & disambiguated problems with error types and messages. That problem is fixed.
New issue: commit referenced before assignment, which I believe was the original issue in the valnet version. Have an appointment, will fix when I get back.
|
Create new classical NRP for the Vedun project
|
|
| May 17, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
6.55 HR |
|
Returning to issue of commit being unassigned when referenced in views.create_order.
Also making said function a little more logical about its choice of default users, and reviewing best practices on raising ValidationErrors
I feel a little dumber about this, but it appears we can circumvent this problem entirely by getting the date from the order creation date (or just datetime.date.today). Using the method that creates these commitments in the first place, there is no way for these commitments to have any other date. However, it's still probably going to fail all the tests, as there is no good reason for commit to be None unless there are no commitments in the DB for the order, unless they failed to be generated. But the tests and the extra diagnostic functions should catch this when the the view function doesn't throw in these locations.
Er, now it's having the receiver issue too... how did that go away temporarily? Maybe it wants the ids? Nah, that was pretty dumb too. Fixed.
Diagnostic shows association flaw in all 3 cases; elaborating that trap. Fix for #510 shows 1 commitment existing after a zero quantity order.
Just to make sure, adding assertion that all commitments are really gone under fix #510.
All 3 of the other tests are showing flaws at the first call, which in all cases is using resource_type.producing_commitments(), so let's start there.
Things that are not the problem with the 3 association issues:
- No commitments generated at all (there is 1)
- Parent RT not associated with (the 1) commitment
- Commitments not associated with event types
- Parent RT not associated with producing process
- Commitment associated with RT not associated with order (the 1 is)
I might have just cracked it, but it will be a pain to really fix. However, if I am right, it should address all 4 problems. The OrderItemForms are not binding to their own controls. That explains why it wouldn't catch the quantity issue, but would stop the items from ever being added to the order. Testing just that hypothesis for now before I make huge changes to fix it. Yeah that has gotta be it. Will start patching it up tomorrow.
|
Create new classical NRP for the Vedun project
|
|
| May 16, 2018 |
Time Contribution |
davidh |
Verdun |
Work - Programming for product |
3.83 HR |
|
Continuing debugging of customer orders and tests thereof.
Adding various prints to narrow down where exactly the resource types go awry.
Typical Output:
recipe created parent RT parent : 87
recipe created child RT child : 88
recipe created grandchild RT grandchild : 89
order_test.setUp sees parent RT parent : 87
order_test.setUp sees child RT child : 88
order_test.setUp sees grandchild RT grandchild : 89
view got RT another changeable : 91; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623710>, 'description': <django.forms.fields.CharField object at 0x46239d0>, 'resource_type_id': <django.forms.fields.CharField object at 0x4623210>, 'url': <django.forms.fields.URLField object at 0x4623150>}
view got RT changeable : 90; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623e10>, 'description': <django.forms.fields.CharField object at 0x46230d0>, 'resource_type_id': <django.forms.fields.CharField object at 0x46231d0>, 'url': <django.forms.fields.URLField object at 0x4623610>}
view got RT parent : 87; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623b90>, 'description': <django.forms.fields.CharField object at 0x4623ed0>, 'resource_type_id': <django.forms.fields.CharField object at 0x4623f50>, 'url': <django.forms.fields.URLField object at 0x4628110>}
Uh huh... two problems are very apparent. First, two unrelated RTs (changeable & another changeable) have made it into the form, Second, the child & grandchild RTs did not make it into the form.
My impression was that there were no RTs at all in the DB at this point, but evidently tests.objects_for_testing.WorkFlowRecipe makes changeable and another changeable. Ultimately this won't be a problem if I can get the right RTs to show up too.
View filters RTs by:
PatternUseCase.objects.get(use_case__identifer="cust_order").pattern.all_resource_types()
or equivalent. Or, not quite equivalent; they use objects.filter(...)[0]...
If there are multiple objects returned that will surely not work. Nope, wasn't that.
Aha. The child and grandchild RTs were lacking resource type facet values that make them appear in the customer order process type.
That did the trick. Prepare confetti. Just need to chop off these response.follow() calls. Put back the confetti.
Tests output:
======================================================================
ERROR: test_create_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest)
Test create_order view
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 181, in test_create_order
process = self.parent.producing_commitments()[0].process
File "/home/valnet/Envs/verdun/lib/python2.7/site-packages/django/db/models/query.py", line 207, in __getitem__
return list(qs)[0]
IndexError: list index out of range
======================================================================
FAIL: test_create_workflow_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest)
Test create_order for a workflow item
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 243, in test_create_workflow_order
self.assertEqual(count, 2)
AssertionError: 0 != 2
======================================================================
FAIL: test_two_workflow_item_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest)
Test create_order for two workflow items
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 283, in test_two_workflow_item_order
self.assertEqual(count, 2)
AssertionError: 0 != 2
Alright obviously in the first case, self.parent.producing_commitments() is empty. That method filters commitments with RT==self whose event_type.relationship=="out" or whose event_type.name=="Receipt". Event types are set up in fixtures, but they do generate one in the test setUp(). Looks like all 3 fails are actually due to this empty query set, but only the first crashes. So it could be either failure to produce these commitments in views.create_order, or failure of commitments to associate to the right event types, processes, process types, patterns, etc etc.
Put together several fault-finding mechanisms to determine whether the test, the association setup, or the actual code is broken. Discovered that the fail-early scenario is playing out; will need to see what I did to validation tomorrow.
|
Create new classical NRP for the Vedun project
|
|
| May 16, 2018 |
Time Contribution |
davidh |
Infrastructure-virtual |
Work - Writing |
2.05 HR |
|
Adding section to Next-Gen NRP doc on a collaborative, forward thinking, machine-readable standard for current and future OVN & NRP implementations to become inter-operable For now, calling it "Structured & Standardized Interoperability".
|
Budget for next p2p generation IT infrastructure
|
|
| May 15, 2018 |
Time Contribution |
davidh |
Infrastructure-virtual |
Work - Meeting |
2.15 HR |
|
Attended workparty.
|
Budget for next p2p generation IT infrastructure
|
|