tritondatacenter / node-ctype Goto Github PK

Release a new minor version with updated npm engines.

Definition (endian != 'big' || endian != 'little') will always return true. I suppose there should be logical and (&&):

if (endian != 'big' && endian != 'little')
throw (new Error('invalid endian type, must be big or ' +
' little'));

Node >= v0.6 has support for a majority of the builtins like readuint8, readuint16, readuint32, etc. We should default to using the ones it has support for, but allow an option for defaulting to the built in ones.

An API dump isn't useful in the README. Rather, it should be short and to the point. API documentation is being changed to series of manual pages.

Robert:

Fun question for your legal team. :)

I've noticed that the license includes copyright held by Joyent. Do we need to get a CLA done for contributions to this repo? If yes, would that be the same CLA as for the main NodeJS project, or would we need to fill out another?

These two functions, which are the only way to handle the values returned by the 64bit read/write functions, are inaccessible by default.

For node v0.6 npm support.

Currently when encountering a char node-ctype defaults to treating this is the equivalent of a one byte char array. This turns out to be inconvenient in several scenarios when interacting with various C structs. By default, a node-ctype will retain its default behavior, but there is now a new option for how to treat these at construction time. It can either be treated as a uint8_t or an int8_t.

I've write a socket client like this:

var usr = "abcdef";
var pwd = "43402F0AB71E1E17094FDAF3CBDD7FEF";

var OP_USERLOGIN_Q = 0x10658;

op_userlogon_q =
    [
        { CommandID : { type : 'int32_t' }},
        { SequenceID : { type : 'int32_t'}},
        { userid : { type : 'char[6]'}},
        { IsFirst : { type : 'int32_t'}},
        { username : { type : 'char[6]'}},
        { password : { type : 'char[32]'}}
    ];

nClient.Main = function()
{
    var ph = new Ctype.Parser({endian : 'little'});//, pd = new Ctype.Parser({endian : 'little'});
    bfh = new Buffer(10),bfd = new Buffer(35),bfs = new Buffer('*'),bfu = new Buffer(usr),bfp = new Buffer(pwd);

    ph.writeData(op_userlogon_q,bfd,0,[OP_USERLOGIN_Q,0,bfu,1,bfu,bfp]);
    bfh = bfh.concat([bfh,bfd]);
}

in struct op_userlogon_q i have to write the usernam of usr and password md5 hash for login,but when writeData throw a error , can tell me why and how?

node-ctype should be able to understand the CTF JSON data as defined in the ctf2json tool specification. node-ctype will parse the data and return a new CType Parser from it.

Missing license information should be uploaded

We reference types in a few places and are not correctly quoting them as strings. That is a mistake.

This has come up enough times, that it'd probably be useful to have.

node-ctype is being checked by javascriptlint. We should commit the configuration file that we use for it. As a part of this ticket, we'll fix any outstanding lint issues.

Please add license information to the package.json.
Documentation is here: https://www.npmjs.org/doc/files/package.json.html

There should be a version changelog that describes the set of tickets fixed in each version release.

the LICENSE file seems MIT allright, but it also states that tools/jsstyle brings its own license. This license is not reflected in package.json's "licenses" tag.

From my reading, it is CDDL-1.0 with copyrights

• 2008 Sun Microsystems, Inc.
• 2011 Joyent, Inc.

this should be reflected in package.json so automated tools correctly compile licenses for an upstream software package.

probably, the package should even include the license text itself (at least, the references in tools/jsstyle are not helpful)

alternatively, is tools/jsstyle even used? i couldnt find any references. it might be the easy option to remove the file altogether

(sorry for submitting an empty ticket first. "i slipped on my mouse")

There appears to be a rogue log statement in resolveTypedef. Time to axe it.

Release CTYPE-26. This represents new functionality; however, all pre-existing functionality will be honored.

The low level API in the README is missing the mention of the 64 bit functions. This should be added.

We've always worked to be jsstyle clean. Now that Dave Pacheco has uploaded it, we're going to integrate it into the repo. As a part of this work, we'll be updating the license file to appropriately describe that jsstyle is not licensed under the MIT license and we'll be fixing small issues along the way.

To fully port C apps to JS we need the ability to parse bitfields from structs.

See http://en.wikipedia.org/wiki/Bit_field for details.

The current entry point for writing out a structure isn't very desirable. Currently one uses the same structure for either both reading and writing data, but you have to also add in the "value" field for the written struct. What would be more convenient is to have a method that took the same struct without the value arg, and then had an additional argument which was an array of values.

The prototype would look something like this:
void CTypeParser.writeDataValues(, values, buffer, offset);

node-ctype is susceptible to the same problems.

Bump the version in the json file.

When parsing a json field, we are treating signed as !signed.

As a part of some of the work done on node, there have been several improvements made to the ctio functions. These should be pulled back into node-ctype.

CTYPE-14 represents an addition of API. Bumping the minor version as appropriate.

Also add support for v0.5, but note we still use our internal implementation for now.

The whole write system needs more rigorous tests and improvements.

I need to package this module for debian GNU/Linux.
could you release a tarball package?

if you need some help about good practices for tarball.
https://wiki.debian.org/UpstreamGuide

Currently this project is not present on the npm registry, it'd be terrific if it were. If you want, I can contribute back a basic package.json file that you can use to publish this project to npm's registry.

It may be worthwhile to have a default option for how to handle 64-bit values. This would be an option on the parser.

Release Terin's bug fixes.

The type definition for a 16 bit integer uses the 8 bit signed read instead of the 16 bit. Thus reading some values will always be incorrect.

Specifying your license in package.json makes it a lot easier for your users to find and comply with GNU Affero licenses.

Also giving licenses (an array of objects with type and url keys) helps users whose legal departments request both the license name and the text. See this example from async:

  "licenses": [{
    "type": "MIT",
    "url": "https://github.com/caolan/async/raw/master/LICENSE"
  }]

Though licenses isn't specified in the npm package.json spec, it is supported by the NPM site, as you'll see if you check async's NPM page.

Thanks!

Hi,

I think wsint64 has a bug with small positive numbers represented in 64bits. When the more significative 32 bits are all zeros vzposwill be false because value[0] * Number.POSITIVE_INFINITY is NaN, causing the number to be considered negative throwing value smaller than minimum allowed value error.

It seems to work fine with all other kinds of signed numbers.

I suggest a PR to fix this and to consider zero a positive number on that function. Do you agree?

Thanks,
Bruno

When working with nested structures there is a mismatch of internal naming. This makes it always consistent as value.

Contrary to the documentation the int64_t and uint64_t are not included in the default types that the CType Parser supports.