Re: [Harbour] Re: Switch to detect undeclared vars being used
Hi, 2010/2/23 Viktor Szakáts : > It means we should name it x:__tonumber(), which > looks a little strange. Plus, it forces using > OOP syntax in non-OOP code. Class(y) does this sort of "type wrapper" or "scalar classes". For example: n := 15 ? n:isKindOf( FooBar() ) // returns .F. This makes the code a lot cleaner. > F.e. in Python which is a strongly type language, > there is no casting, just conversion functions. Python is a dynamically typed language (aka "duck typing"). Best regards, -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Ok Viktor, I suggested the pattern because on other open-source projects I follow and participate, they use the pattern "xx-YY", but I will use the rules for Harbour project. I hope you guys understands that I not trying to impose anything. I'm just trying to help using my knowledge and experience from other spheres! 2010/2/20 Viktor Szakáts : >> It's just a pattern, so we all know that always be "xx-YY" for ALL >> languages and not "xx" for that one and for the other, but for another >> it is "xx-YY", i guess! See! To avoid more things to think about! > > But this pattern is not true to the standard, > it can also be "xx", "xx-YYY", "xx-y-zzz", > see the RFC. Each have different and meaningful > meanings. > >> I've just made an admonition: "en-EN" does not exists. > > I know, that's why I started this discussion > in the first place :) > >> If we follow a pattern, it will be one less thing to be concerned about. :-) > > I think we should follow the standard, > rather than a limited pattern. > > If we invent our own pattern, it will not be possible > to interchange our language code with tools which > adhere to standards. > > BTW we should only worry about this _once_ for each > language we translate our documentation to. So > far we have bits in English and Spanish only, so > it's not very complicated. Moreover IMO we should > first concentrate on English only. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
It's just a pattern, so we all know that always be "xx-YY" for ALL languages and not "xx" for that one and for the other, but for another it is "xx-YY", i guess! See! To avoid more things to think about! I've just made an admonition: "en-EN" does not exists. If we follow a pattern, it will be one less thing to be concerned about. :-) 2010/2/20 Viktor Szakáts : >> It's better to use "en-US", to better distinguish from others and to >> avoid mistakes. We should always follow the pattern "xx-YY". > > Why not 'en-GB' then? I still don't see a good reason to > limit us to any specific dialect, moreover the more > complicated and doubtful we make it, the higher the chances > for a mistake (someone may use 'en', or 'en-GB', or just > miss the casing and there we are). Also, 'en' looks standard > and valid language code. [country ID is optional according > to RFC.] > > Brgds, > Viktor > >> >> 2010/2/20 Viktor Szakáts : >>> Hi Daniel, >>> >>>>>> For example, suppose I want to contribute documenting the hbsqlit3 >>>>>> contrib, wich is module I'm very interested. What I'm suposed to do? >>>>>> Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text >>>>>> files in NF format? >>>>> >>>>> All contribs are meant to be independent from >>>>> core, so their docs should be stored in >>>>> /contrib//doc/en-EN/* >>>>> >>>> >>>> I searched for this "en-EN" locale identifier and it does not exists >>>> [1], [2] and [3]. >>>> It must be changed to "en-US". >>>> >>>> [1] http://tools.ietf.org/html/rfc5646 >>>> [2] http://www.i18nguy.com/unicode/language-identifiers.html >>>> [3] http://en.wikipedia.org/wiki/Language_code >>> >>> Or rather plain 'en'? Can you confirm, if this is >>> the valid ID for dialect-neutral English language? >>> >>> [ Unless we want to even have separate 'US' and 'GB' >>> English dialect docs, which I believe we don't. ] >>> >>> Brgds, >>> Viktor >>> >>> ___ >>> Harbour mailing list (attachment size limit: 40KB) >>> Harbour@harbour-project.org >>> http://lists.harbour-project.org/mailman/listinfo/harbour >>> >>> >> >> >> >> -- >> Daniel Gonçalves >> Base4 Sistemas Ltda. >> [www.base4.com.br] >> [twitter.com/spanazzi] >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
It's better to use "en-US", to better distinguish from others and to avoid mistakes. We should always follow the pattern "xx-YY". 2010/2/20 Viktor Szakáts : > Hi Daniel, > >>>> For example, suppose I want to contribute documenting the hbsqlit3 >>>> contrib, wich is module I'm very interested. What I'm suposed to do? >>>> Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text >>>> files in NF format? >>> >>> All contribs are meant to be independent from >>> core, so their docs should be stored in >>> /contrib//doc/en-EN/* >>> >> >> I searched for this "en-EN" locale identifier and it does not exists >> [1], [2] and [3]. >> It must be changed to "en-US". >> >> [1] http://tools.ietf.org/html/rfc5646 >> [2] http://www.i18nguy.com/unicode/language-identifiers.html >> [3] http://en.wikipedia.org/wiki/Language_code > > Or rather plain 'en'? Can you confirm, if this is > the valid ID for dialect-neutral English language? > > [ Unless we want to even have separate 'US' and 'GB' > English dialect docs, which I believe we don't. ] > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
2010/2/19 Viktor Szakáts : >> For example, suppose I want to contribute documenting the hbsqlit3 >> contrib, wich is module I'm very interested. What I'm suposed to do? >> Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text >> files in NF format? > > All contribs are meant to be independent from > core, so their docs should be stored in > /contrib//doc/en-EN/* > I searched for this "en-EN" locale identifier and it does not exists [1], [2] and [3]. It must be changed to "en-US". [1] http://tools.ietf.org/html/rfc5646 [2] http://www.i18nguy.com/unicode/language-identifiers.html [3] http://en.wikipedia.org/wiki/Language_code Regards! -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? 2010/2/19 Massimo Belgrano : > The next step will be a sync tool between all TXTs in doc/LANG with a > wiki like proposed by Antonio > One way not exclude the other > > 2010/2/19 Bacco : >> On Fri, Feb 19, 2010 at 08:27, Vailton Renato wrote: >>> Hi! >>> >>> >>> >> Is this tool in Delphi too? I dont know if we was thinking the same >> thing, but anyway If yours are in Delphi I still want to do on mine, >> maybe some part can be used on HBIDE. As both tools work in NanForum >> format, both tools can be useful without conflicts. I am really >> focusing on easy of use, handling of all TXTs in doc/LANG and >> contrib/HBNNN/doc/LANG folders without manual loading, and >> multilanguage, but mine is starting and yours seems to be done. At >> least, with your tool and directly into the TXTs maybe someone can >> start writing documentation right now. >> > > > -- > Massimo Belgrano > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Ok! I agree. I'm searching for NanForum file format and google didn't give me any usefull results. I search for hbdoc2 in the harbour sources, but I can't found. Where is hbdoc2 and where can I found information about NanForum file format? Regards! 2010/2/18 Viktor Szakáts : >> IMHO, it would be simpler to create a simple tool to parse the >> NanForum format into a database, for example. From the database, we >> could use php into a site to show and search the documentation, and so >> on. The same kind of tools could generate many other formats, suitable >> to other uses. If someday we leave the NF format, I believe that would >> be better to use more powerful ways to organize the structured data >> for documentation. Note that I am not underestimating the power of >> Sphinx, but it just seemed "too texty" to justify the migration. > > Exactly. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Ok! I'll use the "golden rule" of open-source world with my proposal: "release early, release often"! I've published an example of what we can achieve with Sphinx. But first, keep in mind that it's a less than 3 hour work without a good view of "what next". I talk this afternoon with Vailton about Harbour's documentation and our options, how can we do this and wich tools are widely (wich means accessible and documented) available. We figured out that we have very similar projects: him with his cool wxweb project and me with the apix (api extractor). Both doing almost the same thing. My project goals is to extract documentation blocks from the source and produce HTML output or reST documents that can be embedded in a wider Sphinx based documention project. The problem with api inside sources is just about the developer "culture" and the internationalization is almost impossible (imagine a single source with, say, 20 functions, and four languages documenting each function!). I proposed the use of Sphinx. I started a documentation project and the results can be found here [http://www.base4.com.br/~daniel/hb/index.html]. The sources are also available. Regards! 2010/2/17 Viktor Szakáts : >> 2010/2/17 Viktor Szakáts : >>> Such topic really belongs here, not the users' list. >> we can't impose limitation in argument on userlist >> freedom is magic word, or nobody stay in user list >>> I only had a short peek into it, but IMO it's not best >>> direction to start evaluating (for the 10th time) all >>> the available documentation tools. We've been trough >>> it 1 year ago, 2 years ago... >>> >>> IOW we're over that, NF (NanForum) format is just perfect >>> and the next logical step is to actually write docs :) >> >> we need a path for made a good collaborative work >> without this path nobody can start in help harbour in having a good >> documentation >> so if same body with a good experienced give a way we must evaluate and >> choice if follow it. > > No. Until nobody writes documentation just talk > about it, there won't be documentation. > > It's like if we were discussing what editor or > coding style we should use since 1999 up until > today. Imagine how many lines of code would be > written to date. > > Anyway, anyone can write any documentation BTW, > but I thought it makes sense to flow existing > information instead of reinventing the wheel > again and again. Maybe freedom doesn't allow that, > and you're right. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
