 | XEmusic Beta Testing This is a small game I have been working on, trying to replicate guitar hero (without the 3D). The game (as of right now) is able to take a standard .chart file, and parse it into valid notes. This meens that within a short period of time, you can play any song you want to (with a valid chart file) With the actual Guitar Hero game you have to go through a lot of work just getting the files on, but with XEmusic you can just select a chart, select a song, and play. This is in no way completed, so please leave comments about what you see so far. I am expecting to work on this on and off for a while before I release it. Some people are asking about lisencing of the Note Chart Decoder classes, and as of right now I'm not sure what I should do. Everything is coded in Visual C# using XNA game Studio Express. Note : It is much smoother in real life, but for some reason the video converter, and youtube slowly made it look much worse. Song name - Willing Well II (Coheed & Cambria) |
 | danny53x's Irresistiblement My first actual complete stepfile. FFR = danny53x SMO = yotipo91 Step chart = http://www.bemanistyle.com/parser/getimage.php?m=simfile&f=13/92313irresistiblement.dwi&s=SINGLE&d=SMANIAC&shape=default&color=ddr&spacing=1¬e=type2 Download link = http://www.bemanistyle.com/sims/simfile.php?id=22452 If you find it fun, please rate and download from the link above! |
 | p6apclps #12 Perl 6 Apocalypse http://www.perlfoundation.org/perl6 - - of the standard input filehandle is $*STDIN, but a package may just refer to $STDIN, and it will default to $*STDIN if no package or lexical variable of that name has been declared. [Update: We did s/ STD// on those, so standard input is now just $*IN.] Some of these special variables may actually be cloned for each lexical scope or each thread, so just because a name is in the special global symbol table doesn't mean it always behaves as a global across all modules. In particular, changes to the symbol table that affect how the parser works must be lexically scoped. Just because I install a special rule for my cool new hyperquoting construct doesn't mean everyone else should have to put up with it. In the limiting case, just because I install a Python parser, it shouldn't force other modules into a maze of twisty little whitespace, all alike. Another way to look at it is that all names in the ""*"" package are automatically exported to every package and/ or outer lexical scope. [Update: The names are no longer automatically exported, but you can import them from the global namespace via ""use GLOBALS '$IN', '$OUT';"" and such.] Literals Underscores in Numeric Literals Underscores will be allowed between any two digits within a number. RFC 105: Remove "In string @ must be \@" Fatal Error Fine. [Update: The interpolation rules for arrays have been completely revised. A bare array name no longer interpolates--you have to say @foo[].] RFC 111: Here Docs Terminators (Was Whitespace and Here Docs) Fine. RFC 162: Heredoc contents I think I like option (e) the best: remove whitespace equivalent to the terminator. By default, if it has to dwim, it should dwim assuming that hard tabs are 8 spaces wide. This should not generally pose a problem, since most of the time the tabbing will be consistent throughout anyway, and no dwimming will be necessary. This puts the onus on people using nonstandard tabs to make sure they're consistent so that Perl doesn't have to guess. Any additional mangling can easily be accomplished by a user-defined operator. [Update: Here docs are now just a :to variant on extensible quotes, so any customization you can do to "q/foo/ " you can also do to "q:to/END/". RFC 139: Allow Calling Any Function With a Syntax Like s/// Creative quoting will be allowed with lexical mutataion, but we can't parse "foo(bar)" two different ways simultaneously, and I'm unwilling to prevent people from using parens as quote characters. I don't see how we can reasonably have new quote operators without explicit declaration. And if the utility of a quote-like operator is sufficient, there should be little relative burden in requiring such a declaration. The form of such a declaration is left to the reader as an exercise in function property definition. We may revisit the question later in this series. It's also possible that a quote operator such as "qx/ /" could have a corresponding function name like "quote: qx" that could be invoked as a function. RFC 222: Interpolation of Object Method Calls I've been hankering for methods to interpolate for a long time, so I'm in favor of this RFC. And it'll become doubly important as we move toward encouraging people to use accessor methods to refer to object attributes outside the class itself. I have one "but," however. Since we'll switch to using "." instead of "-]", I think for sanity's sake we may have to require the parentheses, or ""$file.$ext"" is going to give people fits. Not to mention ""$file.ext"". [Update: Nowadays we also require brackets on array interpolations and braces on hash interpolations. See S03 for more.] RFC 226: Selective Interpolation in Single Quotish Context. This proposal has much going for it, but there are also difficulties, and I've come close to rejecting it outright simply because the single-quoting policy of Perl 5 has been successful. And I think the proposal in this RFC for "\I"..."\E" is ugly. (And I'd like to kill "\E" anyway, and use bracketed scopings.) However, I think there is a major "can't get there from here" that we could solve by treating interpolation into single quotes as something hard, not something easy. The basic problem is that it's too easy to run into a "\$" or "\@" (or a "\I" for that matter) that wants to be taken literally. I think we could allow the interpolation of arbitrary expressions into single-quoted strings, but only if we limit it to an unlikely sequence where three or more characters are necessary for recognition. The most efficient mental model would seem to be |
 | ADempiere Default Acct Change Howto make changes to the Default Chart of Accounts data even after reimporting. Introducing the smart tool from Daniel Norin to parse the COA spreadsheet easily in a tree valued format. |
 | Podstawowe typy w .NET część 1 Tutorial predstawia podstawowe typy w .NET: typy liczbowe: typy całkowite i rzeczywiste, łańcuchy tekstowe, znaki, enumeratory, tablice, typ object, konwersje między tymi np. między liczby a łańuchem tekstowym w bezpieczny sposób. Do tego przykład korzystania ze zmiennych i z elementów formatki, czyli etykiet label i pól tekstowych textbox. |
 | PRINTF #1 Printf Documentation PRINTF documentation Editors Note: I have taken the text for this series from : http://en.wikipedia.org/wiki/Printf http://www.opengroup.org/onlinepubs/009695399/functions/printf.html http://www.gnu.org/software/libtool/manual/libc/Formatted-Output-Functions.html http://www.gnu.org/software/gnulib/manual/html_node/printf.html http://www.gnu.org/software/libtool/manual/libc/Formatted-Output-Basics.html#Formatted-Output-Basics http://www.opengroup.org/onlinepubs/009695399/functions/printf.html http://www.gnu.org/software/gnulib/manual/html_node/printf.html POSIX specification: http://www.opengroup.org/susv3xsh/printf.html http://www.gnu.org/software/libtool/manual/libc/Formatted-Output-Functions.html http://www.gnu.org/software/libtool/manual/libc/Formatted-Output-Basics.html#Formatted-Output-Basics http://www.gnu.org/software/libtool/manual/libc/Output-Conversion-Syntax.html#Output-Conversion-Syntax http://www.gnu.org/software/libtool/manual/libc/Table-of-Output-Conversions.html#Table-of-Output-Conversions http://www.gnu.org/software/libtool/manual/libc/Integer-Conversions.html#Integer-Conversions http://www.gnu.org/software/libtool/manual/libc/Floating_002dPoint-Conversions.html#Floating_002dPoint-Conversions http://www.gnu.org/software/libtool/manual/libc/Other-Output-Conversions.html#Other-Output-Conversions http://www.gnu.org/software/libtool/manual/libc/Dynamic-Output.html#Dynamic-Output http://www.gnu.org/software/libtool/manual/libc/Variable-Arguments-Output.html#Variable-Arguments-Output http://www.gnu.org/software/libtool/manual/libc/Parsing-a-Template-String.html#Parsing-a-Template-String |
 | p6apclps #80 Perl 6 Apocalypse http://www.perlfoundation.org/perl6 - - well here, and I'm wondering if it will be too hard to explain in general. I think this is probably too powerful a concept for the typical Perl programmer, who is lucky to understand simple lvalues that always do what they're told. This sort of matching can probably be provided as syntactic warpage, though I'm not sure if that prevents useful optimizations. Anyway, this sort of thing is unlikely to make it into the Perl 6 core unless it generalizes usefully to function argument lists, and it may be too powerful for there too. For that purpose it would resemble a form of overloading, but with the "types" specified by keys. I suspect real types are more useful. RFC 308: Ban Perl hooks into regexes We must be able to call back into Perl code if we want to write parsers conveniently in Perl. Think of how yacc works. Certainly the way that Perl 5 does it is ugly, I'll admit. We can beautify that. But the whole point of Perl is to have all the most useful "Krakken tentacles". And I don't really care if it makes it hard to put the Perl regex engine into some other language. ":-)" RFC 316: Regex modifier for support of chunk processing and prefix matching Infinite strings (via infinite arrays) seem like a more useful concept. It would be easy for the extension subroutine to fail and produce the results desired in this RFC, but without the necessity of the extra syntax specified by the RFC. A match naturally fails when it gets to the end of its string without finishing the pattern. Incremental matching can also easily be done via infinite strings, and the user interface can be a simple as we like, as long as extension rule is somehow associated with the string in question. I think "pos()" is rather too low-level a concept for general use. Certainly it needs to be there, but I think we need some way of implying that one regex is a continuation of a previous one, but within some higher-level syntactic construct, so that it's easy to write parsers without invoking "pos()" or "\g" or "/ c" all over the place. [Update: That turns out to be the ":p" modifier.] "[cut]" Well, I could say a lot more, but that's it for this time. I hope you're excited by all this, in a positive sort of way. But if your jaw lost all of its bounce when it hit the table, I expect Damian's upcoming Exegesis 5 will do a better job of showing how this all fits together into a pretty picture. NAME Apocalypse_06 - Subroutines AUTHOR Larry Wall [larry@wall.org] VERSION Maintainer: Larry Wall [larry@wall.org] Date: 7 Mar 2003 Last Modified: 25 May 2006 Number: 6 Version: 6 This is the Apocalypse on Subroutines. In Perl culture the term "subroutine" conveys the general notion of calling something that returns control automatically when it's done. This "something" that you're calling may go by a more specialized name such as "procedure", "function", "closure", or "method". In Perl 5, all such subroutines were declared using the keyword "sub" regardless of their specialty. For readability, Perl 6 will use alternate keywords to declare special subroutines, but they're still essentially the same thing underneath. Insofar as they all behave similarly, this Apocalypse will have something to say about them. (And if we also leak a few secrets about how method calls work, that will make Apocalypse 12 all the easier--presuming we don't have to un-invent anything between now and then...) Here are the RFCs covered in this Apocalypse. PSA stands for "problem, solution, acceptance", my private rating of how this RFC will fit into Perl 6. I note that none of the RFCs achieved unreserved acceptance this time around. Maybe I'm getting picky in my old age. Or maybe I just can't incorporate anything into Perl without "marking" it... RFC PSA Title --- --- ----- 21 abc Subroutines: Replace C[wantarray] with a generic C[want] function 23 bcc Higher order functions 57 abb Subroutine prototypes and parameters 59 bcr Proposal to utilize C[*] as the prefix to magic subroutines 75 dcr structures and interface definitions 107 adr lvalue subs should receive the rvalue as an argument 118 rrr lvalue subs: parameters, explicit assignment, and wantarray() changes 128 acc Subroutines: Extend subroutine contexts to include name parameters and lazy arguments 132 acr Subroutines should be able to return an lvalue 149 adr Lvalue subroutines: implicit and explicit assignment 154 bdr Simple assignment lvalue subs |
 | Podstawowe typy w .NET część 2 Tutorial predstawia podstawowe typy w .NET: typy liczbowe: typy całkowite i rzeczywiste, łańcuchy tekstowe, znaki, enumeratory, tablice, typ object, konwersje między tymi np. między liczby a łańuchem tekstowym w bezpieczny sposób. Do tego przykład korzystania ze zmiennych i z elementów formatki, czyli etykiet label i pól tekstowych textbox. |
 | Podstawowe typy w .NET część 3 Tutorial predstawia podstawowe typy w .NET: typy liczbowe: typy całkowite i rzeczywiste, łańcuchy tekstowe, znaki, enumeratory, tablice, typ object, konwersje między tymi np. między liczby a łańuchem tekstowym w bezpieczny sposób. Do tego przykład korzystania ze zmiennych i z elementów formatki, czyli etykiet label i pól tekstowych textbox. |
 | p6apclps #72 Perl 6 Apocalypse http://www.perlfoundation.org/perl6 - - ] # find value [( $val eq %hash{$val} )] # assert eq ] } A typical "valuematch" might look like: rule { \s* =\] \s* # match =] $q:=([["'] ]) # match initial quote $0:=( [ \\. | . ]*? ) # return matched value $q # match trailing quote } In essence, the presence or absence of the "valuematch" property controls whether the hash tries to match only keys, or both keys and values. [Update: The above is all completely bogus. A hash's set of keys are simply compiled into a longest-first token match table. The corresponding value contains the closure or rule to fire off when you match, or a number to make the match retry with a shorter key. In addition, there can be more than one hash, as in "[%a|%b|%c]", which are all treated as one for the longest-token rule. See S05.] A hash may be used inside angles as well. In that case, it finds the key by the same method (steps 1 and 2 above), but always treats the corresponding hash value as a regex (regardless of any properties the hash might have). The parse then continues according to the rule found in the hash. For example, we could parse a set of control structures with: rule { [%controls] } The %controls hash can have keys like ""if"" and ""while"" in it. The corresponding entry says how to parse the rest of an "if" or a "while" statement. For example: %controls = ( if =] / [condition] [closure] /, unless =] / [condition] [closure] /, while =] / [condition] [closure] /, until =] / [condition] [closure] /, for =] / [list_expr] [closure] /, loop =] / [loop_controls]? [closure] /, ); So saying: [%controls] is really much as if we'd said: [ if \b [%controls{if}] | unless \b [%controls{unless}] | while \b [%controls{while}] | until \b [%controls{until}] | for \b [%controls{for}] | loop \b [%controls{loop}] ] Only it actually works more like / $k=[{ %controls.prop{ keymatch} // /\w+:/ } ] [%controls{$k}] / [Update: This is also bogus. The keys are treated as a set of tokens with longest-first semantics all keys involved, mapping to arbitrary rules. See S05.] Note that in Perl 6 it's perfectly valid to use "//" inside an expression embedded in a regex delimited by slashes. That's because a regex is no longer considered a string, so we don't have to find the end of it before we parse it. Since we can parse it in one pass, the expression parser can handle the "//" when it gets to it without worrying about the outer slash, and the final slash is recognized as the terminator by the regex parser without having to worry about anything the expression parser saw. A bare subroutine call may be used in a regex, provided it starts with "&" and uses parentheses around the arguments. The return value of the subroutine is matched literally. The subroutine may have side effects, and may throw an exception to fail. Defining Your Own Rules Suppose your name is Hugo and you don't like to use "!" to negate an assertion. You can define your own assertion like this: my rule not (str $rx) { [![{"[$rx]"}]] } # define Hugo not / [not [a-z]] / # same as [![a-z] ] That rule would be lexically scoped because of the "my". If you think it looks like a "sub" declaration, you're right. In fact, it's possible you could even declare it anonymously like a closure: my $not = rule (str $rx) { [![{"[$rx]"} ]] }; / [$not tonight dear] / But maybe you don't want it lexically scoped because you're writing a grammar for general use: grammar HugoGrammar { rule not ($rx) { [!$rx] } rule identifier { [not before \d] \w+ } rule \j { \c[LF] } rule parse { ^ [identifier] \j $ } } HugoGrammar.parse($line); In this case a rule is simply a method in a grammar class, and a grammar class is any class derived implicitly or explicitly from the universal RULE grammar class. The built-in regex assertions like "[before \w]" are really just calls to methods in the RULE class. The namespace of a grammar is simply the method namespace of the current class, which is the class's methods plus all inherited methods. [Update: Nowadays it's the "Regex" class, or some derivative.] In addition to normal subrules, we allow some funny looking method |
العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
Español
