Robert Shiplett's Blog

RE: Kudos for Curl IDE 6.0.5

Duke — Fri, 05 Dec 2008 22:13:30 GMT

I've made a new bug report for this, and we should be able to fix a future 6.0 IDE service pack to not put the incompatible stuff into the 3.0 .cprj file.

RE: Kudos for Curl IDE 6.0.5

rshiplett — Wed, 03 Dec 2008 20:12:17 GMT

This appears to be a persisting bug ...

I just made a change which affected a 3.0 project CPRJ file in 6.0.1005 IDE and I find this change in the CPRJ:

{project
version = 2,
manifest-location = "manifest-CNTRL-DSKTP.mcurl",
api-version = "3.0",
use-style-sheets? = false,
style-package-name = "",
style-sheet-name = "",
{target
name = "local",
|| abridged
|| as you know this will not load as a cprj into a 3.x IDE because of the
style-sheet meta-data

This although use style sheets was not selected ( it may be defaulting to true for pre-5.x projects )

RE: Kudos for Curl IDE 6.0.5

rshiplett — Mon, 01 Dec 2008 15:19:28 GMT

When I have time I will re-install ( as it may have been the Nitro IDE )

The problem is gone: it was a real nuisance whenever I had a 3.x project change to commit to version control when edit was done in the more recent IDE

If I find that it was Nitro, I will file the bug report.

RE: Kudos for Curl IDE 6.0.5

Duke — Thu, 20 Nov 2008 22:53:32 GMT

Sounds like a report of a bug fix, although I could not find an explicit mention of this in our bug database.

RE: Kudos for Curl IDE 6.0.5

cbarber — Thu, 20 Nov 2008 21:49:06 GMT

I am confused. Are you trying to report a bug?

RE: tip for the Curl Documentation Viewer

Porcari — Tue, 11 Nov 2008 04:59:56 GMT

Great.

RE: On improving the options which promote Curl production-quality code

cbarber — Thu, 30 Oct 2008 16:04:06 GMT

Everything I write on this website are my personal views and should be taken as such. I am the architect of the compiler team, and am in some sense a gate-keeper for Curl language changes, and I have a lot of personal experience in both successfully and unsuccessfully proposing language changes. So I am speaking from my own knowledge and experience but not stating Curl's official position.

Curl has implemented many features as a result of requests from our customers in Japan or in direct response to issues and problems they have faced. Probably most of our recent work on RecordGrid and various controls came out of customer requests. Of course, these issues always get filtered through our organization in Japan, so I have no idea how many originate with particular users.

Regarding the request for a new type of curl herald, I don't think I understand how allowing something other than a single class in a file represents a security issue. I can see why it might represent a maintainability issue and why you might want to adopt that coding practice, and why you might want an automated way to enforce that practice, but I think I need a little more context to understand what exactly the security issue might be. We have had many people with Java experience work with Curl, and this is the first time I have heard anyone express a need for such a feature.

I do not think that a special language syntax is the best way to solve this particular issue for a number of reasons:

1) This type of assertion does not require special compiler state to check. It would not be difficult to write a Curl script or applet for doing such a check, given an appropriate indicator for what files should contain only a single class (such as a special comment or a new file extension like '.ccurl'). Ideally, such a feature would be provided by the IDE or a separate Eclipse plugin.

2) Implementing such a syntax in the compiler would not be entirely trivial. In particular, such syntax would need to be stripped out or handled specially by pcurl-file/flatten-curl-file. If implemented as a 'curl', herald it would require adding many special case checks to the existing code supporting that syntax. It would be easier to support as a new syntax. But even genuinely trivial changes to the language or parts of the standard API require us to write up a detailed proposal and subject it to an internal review process.

3) Any language change would have to wait until the next major release after 7.0, which will not come out for a long time. Given that other solutions seem to be available for this problem, anyone interested in this feature would get satisfaction a lot sooner if they were to pursue another solution.

Even if we were to implement a special syntax for this purpose, I don't think it would be a special 'curl' herald, since that would introduce a usage that would not be consistent with our other uses.

What I would suggest, is that you adopt a special extension, such as .ccurl, for files that are intended to only contain a single class, and then write a file verifier to check that the file does contain only one class. For now, you could run your checker script as part of an automated build process or as a pre-check-in hook in your source code control system (if supported, of course). In the meantime, the IDE team can consider the feasibility of supporting user-provided code-checkers directly in the IDE; this is a feature I would strongly support.

I understand your frustration, and you should in no way hesitate to request features that you think may be useful. But you do need to understand that we also do not have the resources to implement every good feature that someone might want.

RE: On improving the options which promote Curl production-quality code

rshiplett — Thu, 30 Oct 2008 02:00:23 GMT

I would like to hear from Curl whether these are your personal views or the views of Curl Corp and Sumisho.
Can you point to a single user suggestion which Curl Corp has acted on in the past 12 - 18 months? (and I do not mean bug reports or obvious PRO IDE defects)

Richard? Bert?

A recent suggestion of mine on which Curl acted to deal with build automation on Win32 does not count: it was not a suggestion of mine as a user, but a client requirement from a business partner.

I spend a great deal of my time in Curl code reviews and disagree with you utterly.

Utterly and completely.

We could be on two different planets: daily user and official gate-keeper? Or are these your personal reactions? Your tone is suggests that you speak for Curl Corp.

I would appreciate the simple courtesy of a response such as
"Speaking for Curl Corporation, ...
versus
"In my personal opinion, ...

If in any post to a blog I were speaking for my employer, I would make it very clear, I can assure you.

The view that this is just a matter of "style" is nonsense when compared to any of the options available in other expression-based languages.

The code reviews which I perform suggest that Curl has a lot to learn in PITL from other languages and platforms. Those changes will not be provided by the move to Eclipse in and of itself. I use languages other than Java in Eclipse and am convinced on that point.

Perhaps you have not spent enough time explaining to senior JAVA staff that an SCURL file must be viewed as a script and treated as suspect because there is in fact no assurance available within the Curl platform that the file is what it says it is. This introduces needless security issues which are not solved by GREP.

My pleas to gently nudge Curl towards the OPTION of a simple header for SCURL files - such a simple matter - appear to have fallen on deaf ears. That you "don't think there is a string enough reason" does not impress me one wit. But if Bert and Doug and others agree, that will be another matter.

This is one reason why we need some kind of forum to air the issues that senior Curl users face on a daily basis: this is clearly not that forum. It was my understanding that Richard Monson-Haefel would be trying to mediate for the developer community and my suggestion arose out of his invitation on his blog. But notably he has not responded to this post.

In the course of the past 12 months there has been no opportunity speak freely and hear responses from Curl Corp. at least in the English-speaking world.

It is immensely frustrating as you clearly fail to grasp the issue where corporate code repositories and source code files are concerned in secure environments under source code version management.

I would very much appreciate the use of personal mail for further comment and that some other person either comment or let this matter lie.

RE: On improving the options which promote Curl production-quality code

cbarber — Wed, 29 Oct 2008 17:22:12 GMT

I don't think there is a strong enough reason to add a single class declaration. As I have said, it is entirely a matter of style. If you want to only have one class per file, you can do that. I typically prefer one class per file myself, but often use more than one for small classes that are closely related.

If you want to enforce a one-class-per-file coding standard you only need to pick an enforcement mechanism, which could range from simple human code reviews to simple scripts that grep for define-class.

RE: On improving the options which promote Curl production-quality code

cbarber — Wed, 29 Oct 2008 17:12:02 GMT

I am sure that Curl is already powerful enough to implement a decent rule engine without adding any language features, should someone want to do so. But we don't have any plans to build such a library ourselves at this time.