All Activity

That's the first time I've heard of such a problem. I'm reluctant to implement this because from experience, synchronous R/W usually causes more problems that it solves. Would you be willing to privately share the code with me? What kind of serial port are you using? Can you try using a FTDI-based USB-Serial converter to see if you get the same behavior? Other USB-serial converters that perform well with VISA are: https://www.sealevel.com/product/2105r-usb-to-1-port-rs-232-db9-serial-interface-adapter/ https://www.moxa.com/en/products/industrial-edge-connectivity/usb-to-serial-co

Hi Porter, we have run into an issue with an EXE getting completely stuck and traced it to the VISA read (or write or both, can't remember) being configured to the async mode. This is in LV 2015 with VISA 15 (and I believe it was also tested with VISA 18.5, which was the latest supported version). Would it be possible to add a boolean property to the class to allow making the R/W calls in sync mode? Should be as simple as adding a case structure with a second copy of the node.

Possibly in this case as it has searching. But we wouldn't have to write parsers if the current primitives were useful I don't know what the current status of the G toolkit is, since the last person that took over maintenance and release is no longer active on this forum. That's fair enough and I'm sure appreciated. However JSON Schema - if that's your target - isn't an edge case. Your Lineator would be the place to implement that, so I'm confused by the comment "long way to go" for a library that I think is pretty much feature complete.

Dont misunderstand me: I think it’s a great toolkit, and I think it should be a G toolkit not a language primitive. I’m just finding it’s edge cases. 🙂

That's funny actually. I used to think this stuff didn't matter anymore until I was put in projects where that stuff is suddenly relevant. A lot of the stuff we make has to be right once they leave my hands. Otherwise its GG M8 try better next time. For example in C I've had to pay attention to things I never paid attention to way back then, like sticking to memory with hard limits / avoiding dynamic memory. Not using recursion to not abuse the stack, etc. (Really low powered/cheap weak embedded chips) Upper bounds in execution, etc. Or use different kinds of standards/guidelines for

It would be interesting if anyone has a similar document specific to Labview code. NI has a style guide hanging around, it is useful but definitely not the same thing.

AQ's Character Lineator

Indeed. I don't know what AQ is referring to with CL (Command Line? Common Lisp?) but I have a feeling he has an eye on the library supporting JSON Schema-another IETF brain-fart which made HTML a nightmare until they ditched it and brought us XML. They have a habit of taking nice simple solutions and "formalising" them them into bloated, complicated solutions that nobody uses. I think the library is pretty much feature complete at this point-maybe some data types missing but can't think of any off the top of my head - so this sounds peculiar...unless JSON schema is your target. R

The Object thing is not where I would spend limited effort in performance improvements, as I would expect the User to actually use the item Values and thus require a copy at some point. I would rather improve the JSONpath search algorithm.

I hope Users can do whatever they want using the lower-level functions plus subJSON with the <JSON> tag.

There is support for Sets and Maps in the latest version; I wouldn't want such things require any kind of "hook".

I've seen a similar error dialog accompanied with a crash report. From those logs, I gathered it might also mean that there is not enough contiguous memory available. Perhaps "Largest Available Memory Block" can be of interest as well.

Kind of. The JSONText VIs are more efficient overall than my originals that I slapped together in a weekend. But the current JSONText VIs do have some inefficiencies that my originals didn’t have (most notably, see the earlier post about accessing all fields of an object) that crop up when translating schemas. And the single serializer hook is insufficient to do some operations — support for sets/maps or custom translations of complex data structures, for example. These are things that the CL architecture accounts for that I wish JSONText was refactored to support. Having said that, I’m happy

A paean to the utility of JSONText.

Alternative (6): all attributes are returned as JSON values. Rather than get the attribute as the actual type, the User would get the attribute as a string, then use From JSON to convert to type. One could make VIMs that combine these two steps, and these VIMs might possibly be made to work with non-JSON attributes as well.

@ShaunR "Didn't that do JSON?" Yes. Initially I rolled my own JSON parser, but it was rewritten to call JSONText as subVIs. The Character Lineator is a better framework (my opinion) for importing and exporting objects into/out of JSON than trying to hook the serializer directly. Raw JSON doesn't provide any schema version management nor any data massaging capacities. It's just fields without context. The JSONText library is important for the raw string handling. You need more infrastructure sitting above it to actually use JSON. CL is one possible choice for that infrastructure. The serializ

@Aristos Queue Off topic I know. But whatever happened to AQ Character Lineator INI Serializer/Deserializer Didn't that do JSON?

It has pros and cons. It is definitely a nice change of pace. 🙂

I generally prefer #4 straight up. If you add #5, anyone not supplying the types will be slowed down by the code checking the input variant for "Did you provide a type for this attribute? How about this attribute?" and getting a "no" answer each time. It's not slow, but it is an unnecessary hiccup. Anyone who knows the types can get them from the generated variant. The one difficulty that makes me lean toward #5 is objects. If we parse "a":5 then we know to add attribute "a" as an integer. But if we hit "a":{ ... } then that can be a cluster of those elements, another variant attribute ta

The To-JSON behaviour was copied from the previous LAVA-JSON library. That library had the reverse operation, but it only worked if one provided same-named attributes in the default value. As you point out, this is because we need to know what type to convert the JSON to. Personally, I found this kind of useless, as the whole point of attributes is to have unknown items of unknown type. I had also developed "subJSON" for exactly this use case, and never use Variant Attributes at all. So it kind of got stuck in limbo. I note that the newer Set and Map support doesn't run into this

I think AQ is enjoying this role as the end user instead of the LV programmer 🤣 I do appreciate following these edge cases though. I use this tool widely and it is fantastic.

The handling of variant attributes is asymmetric. I can serialize the variant and its attributes are recorded as fields of an object. But on deserialize, the attributes are not recovered. I suspect this is because there isn't any type information to tell us what type each attribute should be, but I'm not sure. Why isn't the deserialize handled? Can it be handled?

Source

Refactoring and re-architecting are slightly different things. The main difference is scope, intent and risk but how you achieve them may be similar. Refactoring is to improve maintainability, readability and complexity. This has less risk to the overall behaviour of the software and sub VI'ing will do this effortlessly. Re-architecting is to improve the logical operation of how you achieve external behaviours. It's to improve modularity, interoperability and cohesion . This is a much riskier proposition. You cannot re-architect spaghetti code without first refactoring but while you

In my opinion, subVi-ing is only a small thing. There are so many ways something can be solved, and in a long term project that was started as a newbie it can mean a huge mess if you start mixing these ways. SubVI-ing only makes it prettier but the underlying architecture is still going to be a huge mess. These messy mid-sized projects are very hard to refractor, because it's simply very hard to test throughoutly if you didn't document testing all the way through the project, which you probably haven't if you made such a mess in the first place. Most of my late cleaning-ups ended up