I found an issue in an Electronics Design Automation proprietary language and decided to look it up to see how things were handled in SystemVerilog and found that the LRM just skated over a topic that needs clarification.
I tried to find a blog or email on the IEEE and Accellera sites but failed.
My question is: how do I contact that IEE group working on SystemVerilog, to indicate an issue that could do with clarification in their spec?
Thanks :-)
I am a member of the IEEE working group.
The IEEE has a bug tracking system that you visit as a guest to see if the issue is already reported. You can also post your issue on a popular SystemVerilog forum like https://verificationacademy.com/forums/systemverilog or https://www.quora.com/topic/SystemVerilog and there is usually someone for the group there to respond.
Related
I ask here a question about the PLCopen specification over Codesys SIL2 package. I've already asked this on Codesys Forge Fourm, without reply. It seems that on that forum no-one reply to safety questions.
Reading the Codesys SIL2 user manual I can't understand the worth of the PLCopen specification. I report from the manual:
Chapter 1.3: "Aderence to the safety requirements listed in Appendix 7.4 is absolutely necessary."
Safety requiment 3-4.5 (from appendix 7.4): "The permitted programming languages for the programming of a Codesys Safety SIL2 controller are listed in chapter 5."
Chapter 5 (about programming): "...The rules are only raccommendations that enable the certification to be simplified...".
Chapter 5 reports almost all the PLCopen specification, with some little differences. So, I can't understand if it's necessary to use the "chapter 5 rules" to program SIL2 ECU or if those allow a simpler certification of the system.
Someone has ever stucked with this issue?
Thanks,
Francesco
We have some clients who, upon attempting to submit a form, are recieving the error - "HTTP Status 501 Method OST is not defined in RFC 2068 and is not supported by the Servlet API" being thrown by Apache Tomcat/6.0.29.. Apparently, this error is only being received by users running Firefox on Windows 7.
After a lot of digging, the vast majority of examples of Method = "OST" that I can find are on Chinese language websites.. Like here.. In This discussion (English language) "Quoted Printable Transfer Encoding" was mentioned as the possible cause of a similar problem, but it does not involve Apache Tomcat, or any particular browser/operating system combination.
I have a feeling that this issue is something to do with encoding, but have little experience relating to this.. Has anyone experienced a similar issue, or perhaps have some suggestions as to how I might go about solving it?
Thanks
It may be useful to have a look at the following known and recorded defect in Mozilla Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=723805
This seems relevant to your problem, and it may shed some light on how you could do things a bit differently to avoid it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've been looking at some open-source XMPP servers, and am familiar with the official page http://xmpp.org/. But thus far I've not found anything in between "The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication" and a list of XEP specifications. For instance articles explaining the basics and terminology - stanzas, IQ, presence, etc, etc. Even the Wikipedia page misses this, unsurprisingly the open-source projects assume you know these things before you start digging into the code.
Is there a good, (semi-)official set of tutorials on this? Do I need to be looking for Jabber resources rather than XMPP?
Amongst other things, I'd hope to see diagrams for use-cases and flow, not just dry protocol text. I know books on XMPP exist, but generally anything in a book is available in some form online too.
This is probably way too basic, but at least it's technical: https://web.archive.org/web/20170916193014/http://www.adarshr.com/fun-with-xmpp-and-google-talk and the second part, https://web.archive.org/web/20171005104211/http://www.adarshr.com:80/fun-with-xmpp-and-google-talk-part-2
It explains what stanzas are, what types are available and stuff.
Here is what got me startet on XMPP Development:
A good book: XMPP The Definivie Guide
A mature Java API. I've chosen the Smack Library from Ignite Realtime and used the groovy language with a buch of small scripts to learn the basics.
Later i developed a plugin for the OpenFire XMPP Server. There are some tutorials and a forum on their site as well. I think that both the smack and the openfire api's are easy to learn.
If you are not into java: The book referes to the SkeekXMPP Python library and it uses it to create some examples (echo bot, ...).
As others have said, the specifications are a good introduction. It's true that they are technical in nature, and worded to be precise - but they are really some of the best specifications I've seen for any protocol, especially the latest RFCs (6120 and 6121) which clarify some of the grey areas in the originals.
E.g. you mention wanting to know the definition of a stanza, it's explained (with examples) in 6120 section 8.
If you have any feedback on how the specifications can be made clearer, then say so on the XMPP mailing list, where all feedback is considered for the next drafts of the specifications.
If the specifications are really too much for you (I appreciate some people like more pictures than I do), do consider the book (whether in paper or digital form) - it's designed exactly as an easy introduction to both the core specifications and the most common extensions, and written by people who help develop and implement them.
The RFCs (listed on the Wikipedia page) should be a quite good introduction to this topic.
For example: RFC3920: Extensible Messaging and Presence Protocol (XMPP): Core
This might be an old question, but I just wanted to keep the process I used in order to learn XMPP.
A few years ago, a few friends of mine and I were learning about how to leverage XMPP, and understanding how it fits into larger piece is quite a tedious task. I highly recommend starting off by reading the wikipedia page of XMPP:
http://en.wikipedia.org/wiki/XMPP
You'll be surprised how many people aren't able to answer questions about XMPP which are the most fundamental.
I also highly recommend reading this article:
http://www.infoworld.com/article/2682116/application-development/xmpp-rises-to-face-simple-standard.html
It'll give you a sense of the motivation behind XMPP, it's history, and it's protocols that used to be on par with it.
From there, it'll be best to read the sources of the wikipedia page to give a more indept understanding of any features you might be interested in with XMPP.
Use the xmpp asmack library from
http://beem-project.com/projects/beem/files
download asmack-android-7-beem-jingle.jar
and documentation of
http://www.igniterealtime.org/downloads/index.jsp
Hope it helps others like it helped me
Install openfire on server side and use qsmack on android side.
some time ago I found an article (Roles: Composable Units of Object Behavior) describing the pros of using Roles versus Interfaces or other ways of dealing with behavior requirements. Does any of you knows where I can find more literature about that, or knows more about Roles?
I know that that's almost a research topic, but maybe someone (maybe some Perl programmer) has tried something with it (Moose?).
Note: the reason for adding tag "perl" is that maybe Perl programmers are more likely to give an answer.
For Moose based examples, you should check this and that example and this specification.
ETA: For the theoretical aspects, see this page
At work I am responsible for writing specifications quite often and I am also the person who insisted on getting specifications in the first place. The problem is I am unsure how specifications should look and what they should contain. A lot of the time when my boss is writing the specifications (we are both inexperienced in it) they put in table names and things that I don't think belong there. So what is a good way to learn to write a good spec?
EDIT: Should a functional spec include things like assuming I am specifying a web application, the input types (a textbox, dropdown list, etc)?
The most important part of development documentation in my opinion, is having the correct person do it.
Requirements Docs - Users + Business Analyst
Functional Spec - Business Analyst + developer
Technical Spec (how the functionality will actually be implemented) - Sr. Developer /
Architect
Time estimates for scheduling purposes - The specific developer assigned to the task
Having anyone besides the Sr. Developer / Architect define table structures / interfaces etc. is an exercise in futility - as the more experienced developer will generally throw most of it out.
Wikipedia is actually a good start for the Functional Spec, which seems similar to your Spec - http://en.wikipedia.org/wiki/Functional_specification.
There's a great chapter in Steve McConnell's Code Complete that runs through specification documents and what they should contain.
When I was tasked to build an Architecture and Business Analysis team at a company that had never had either, I used McConnell's spec chapter to create the outline for the Technical Specification document. It evolved over time, but by starting out with this framework I made sure we didn't miss anything and it turned out to be surprisingly usable.
When writing specs, a rule of thumb I follow is to try to have technical documents always start from the general and move to the specific -- always restate the business problem(s) or goal(s) that the technical solution is being developed to solve, so the person reading the spec doesn't need to go to other documents to put it in any sort of context.
See Painless Functional Specs by Joel Spolsky.
Some of the things he says every spec should have:
A disclaimer
An author. One author
Scenarios
Nongoals
An Overview
Details, details, details
Open Issues
Side notes
The important thing is to get something written down rather than worry about the format.
Buy Books:
Requirements Engineering by Ian Sommerville & Pete Sawyer ISBN 0-471-97444-7
or
Software Requirements by Karl Wiegers ISBN 0-7356-0631-5