Totally, I would tend toward some syntax that is already used/accepted.
On Fri, Sep 2, 2011 at 7:41 PM, j...@rejon.org wrote:
> we need to restart this discussion
>
>
> On Tue, Mar 15, 2011 at 2:00 AM, Jakub Jankiewicz wrote:
>
>> I don't like this
>>
>> sql statement
>>
>> And adding for for a
we need to restart this discussion
On Tue, Mar 15, 2011 at 2:00 AM, Jakub Jankiewicz wrote:
> I don't like this
>
> sql statement
>
> And adding for for and if is not inventing a language. It's just like C
> preprocesor, This are importer because user will use AIKI not PHP. and
> functions which
Hi guys, while Aiki Markup is not ideal, I cleaned up the documentation.
In making comments on the code, I've noticed many undocumented markup
and have been adding them to this page.
http://www.aikiframework.org/wiki/Aikimarkup
For Aiki Markup 2, I'm wavering between nuking current markup all th
Did you get that minilanguage outlined Jakub?
On Sat, Mar 19, 2011 at 9:08 AM, Bassel Safadi wrote:
> Good article
>
> On Wed, Mar 16, 2011 at 8:05 AM, Jakub Jankiewicz wrote:
>>
>> If you don't read this already you should "Designing Minilanguages"
>> chapter in The Art of Unix Programming by E
ok, lets see that wiki page updated and completeand some commits on
modular implementationotherwise its vaporous!
On Tue, Mar 22, 2011 at 9:46 PM, Jakub Jankiewicz wrote:
> new Aiki will be better and with new cool stuff, so they should
> eventually upgrade.
>
--
Jon Phillips
http://rejon
new Aiki will be better and with new cool stuff, so they should
eventually upgrade.
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-deve
OK but think it should be pushed back. If users want to use old aikimarkup
then they have to convert their site in order to upgrade.
j...@fabricatorz.com
http://fabricatorz.com
On Mar 21, 2011 2:56 AM, "Jakub Jankiewicz" wrote:
> No need to maintain. It will be like dead code for new AIKI apps an
No need to maintain. It will be like dead code for new AIKI apps and
only old one will use it.
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikifra
Dnia 2011-03-20, o godz. 08:01:37
chovynz napisał(a):
> Please excuse my ignorance.
> Why keep backwards compatibility? bloatware much?
Because it's very importent for users to use new iproved version of
AIKI using old apps. Example: Python 3.
___
Mai
On Sat, 2011-03-19 at 08:31 +0100, Jakub Jankiewicz wrote:
> until AIKI 1.0 support for both
>
>
>
> and
>
>
>
> in the same widget and remove php in 1.0
I don't see why we need to remove aiki's parsed php so quickly. I think
better to do like in 1.5 or even 2.0.
but first, lets agree upon
ocal is one of them.
but keeping broken (illogical, or spelling mistaked, not working/could be
better) code doesn't make sense to me.
On Sun, Mar 20, 2011 at 8:02 AM, j...@rejon.org wrote:
> We have sites that use current aikimarkup.
>
> j...@fabricatorz.com
> http://fabricatorz.com
> On Mar 19,
The reason I ask is when the backwards is broken, why bother to keep it?
When the first is not good why not make it better and change it?
A simple example:
(#(inherent)#) is not correct.
IMHO much better to update to only accept
(#(inherit)#)
instead of keeping both (2x the code to maintan)
On Su
We have sites that use current aikimarkup.
j...@fabricatorz.com
http://fabricatorz.com
On Mar 19, 2011 2:01 PM, "chovynz" wrote:
> Please excuse my ignorance.
> Why keep backwards compatibility? bloatware much?
___
Mailing list: https://launchpad.net/~a
Please excuse my ignorance.
Why keep backwards compatibility? bloatware much?
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-devel
More
Good article
On Wed, Mar 16, 2011 at 8:05 AM, Jakub Jankiewicz wrote:
>
> If you don't read this already you should "Designing Minilanguages"
> chapter in The Art of Unix Programming by Eric Steven Raymond
>
> http://www.faqs.org/docs/artu/ch08s03.html
>
> __
until AIKI 1.0 support for both
and
in the same widget and remove php in 1.0
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-de
all awesome, we should imo, freeze current aiki markup and version
somehow, spec out aiki markup 2 on the wiki and make agreement between
us talking about this when ready and then hack in the new
aiki-markup...of course, will have to keep the old shit, but need to
make sure our future work is versi
Dnia 2011-03-19, o godz. 02:21:26
Bassel Safadi napisał(a):
> those functions currently can also be accessed like:
> widget->ineherit((!(1)!)); php>
Awesome can you add
query("SELECT * from aiki_widgets") php>
I just left default one it should be $0 - FULL URI and $1.. URI parts
parts.
> but
(query "SELCT id from aiki_users"
(if event($id)
(query "SELECT filename from ocal_files where userid = $id"
$filename
)
(else
nop
)
)
(if foo(10)
lorem
(else
(if bar(20)
ipsum
)
)
query "SELCT id from aiki_users" {
if event($id)
Sql queries are for loops in aiki, still don't see why we need to write down
for loop when it auto work
2011/3/19 Roger Martín
>
> If we include `if` and `for` aiki will be more flexible and allow to
>>
>> create shorter widget that do more.
>>
>>
> totally agreewe must include for and if, b
PEG parser for S-Expressions will be pretty simple so all we'll need to
do is to write interpreter which call aiki core.
The same as (aiki( )). And you need a parser because inside (aiki( ))
may be another aiki.
what about
(aiki( statement [;statement]*))
(aiki( statement [;statement]*)
)
yeah agree on the need to have better markup for if then statements, roger
already did good work on that. but I think we need to discuss more on this
on its own blueprint
2011/3/18 Jakub Jankiewicz
> Dnia 2011-03-18, o godz. 21:43:42
> Roger Martín napisał(a):
>
> > >
> > > Should be thinking g
what is blocking OCAL development now because of the current panel?
On Fri, Mar 18, 2011 at 12:46 PM, Jakub Jankiewicz wrote:
> When we create better panel we'll be able to fix OCAL faster.
>
> ___
> Mailing list: https://launchpad.net/~aikiframework-d
On Fri, Mar 18, 2011 at 10:45 AM, Roger Martín wrote:
> Agree rejon, but a long voyage begin with short steps.
>
>
> Totally. here are the priorities I see that are blocking aiki from more
>> use:
>>
>> 1.) admin interface is shit.
>> SOLUTION: Make mockup of new interface, allow any sysGOD/root
On Fri, Mar 18, 2011 at 12:54 AM, j...@rejon.org wrote:
> Totally. here are the priorities I see that are blocking aiki from more
> use:
>
> 1.) admin interface is shit.
> SOLUTION: Make mockup of new interface, allow any sysGOD/root change
> admin interfaces
>
>
I don't think it's time for new m
thanks for the suggestions Jackub, I think we need to discuss each one of
those on it's own, so would be great if you can take it a step further and
file a blue print for each one, there is a lot to say about each situation,
please find bellow what I think about some of the cases
On Thu, Mar 17, 2
Agree. Why you need this comas?
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-devel
More help : https://help.launchpad.net/ListHelp
Can you guys please flesh out your ideas more on the wiki page. Lets do
before sever too farlisp/scheme is great IMO.
j...@fabricatorz.com
http://fabricatorz.com
On Mar 18, 2011 5:47 PM, "j...@rejon.org" wrote:
> Lisp baby!
>
> j...@fabricatorz.com
> http://fabricatorz.com
> On Mar 18, 2011 5
Lisp baby!
j...@fabricatorz.com
http://fabricatorz.com
On Mar 18, 2011 5:39 PM, "Roger Martín" wrote:
>> If we include `if` and `for` aiki will be more flexible and allow to
>> create shorter widget that do more.
>>
>>
> totally agreewe must include for and if, but when i think in ocal
> libr
> If we include `if` and `for` aiki will be more flexible and allow to
> create shorter widget that do more.
>
>
totally agreewe must include for and if, but when i think in ocal
librarians and their work making widget, i prefer ADD a shortcode
like:
(aiki walker("SELECT username FROM aiki_us
Dnia 2011-03-18, o godz. 21:43:42
Roger Martín napisał(a):
> >
> > Should be thinking global aiki though and not just ocal
> >
>
> sorry...;-)
> ocal->clipartThumb("SELECT ..FROM AIKI WHERE $1") aiki>
> openfont->list("SELECT * FROM fonts WHERE ...") aiki>
> openfont->specimen($1) aiki>
> forwar
How to express in aikilisp?
j...@fabricatorz.com
http://fabricatorz.com
On Mar 18, 2011 3:43 PM, "Roger Martín" wrote:
>>
>> Should be thinking global aiki though and not just ocal
>>
>
> sorry...;-)
> ocal->clipartThumb("SELECT ..FROM AIKI WHERE $1") aiki>
> openfont->list("SELECT * FROM fonts W
Dnia 2011-03-18, o godz. 21:43:42
Roger Martín napisał(a):
> >
> > Should be thinking global aiki though and not just ocal
> >
>
> sorry...;-)
> ocal->clipartThumb("SELECT ..FROM AIKI WHERE $1") aiki>
> openfont->list("SELECT * FROM fonts WHERE ...") aiki>
> openfont->specimen($1) aiki>
> forwar
>
> Should be thinking global aiki though and not just ocal
>
sorry...;-)
ocal->clipartThumb("SELECT ..FROM AIKI WHERE $1") aiki>
openfont->list("SELECT * FROM fonts WHERE ...") aiki>
openfont->specimen($1) aiki>
forward->places("SELECT * FROM...")
___
M
totally agree...jakub, hang in #aiki irc.freenode.net
2011/3/18 Jakub Jankiewicz :
> Dnia 2011-03-18, o godz. 08:22:45
> "j...@rejon.org" napisał(a):
>
>> Should be thinking global aiki though and not just ocal
>>
>> j...@fabricatorz.com
>> http://fabricatorz.com
>> On Mar 18, 2011 5:47 AM, "Jaku
Dnia 2011-03-18, o godz. 08:22:45
"j...@rejon.org" napisał(a):
> Should be thinking global aiki though and not just ocal
>
> j...@fabricatorz.com
> http://fabricatorz.com
> On Mar 18, 2011 5:47 AM, "Jakub Jankiewicz" wrote:
> > When we create better panel we'll be able to fix OCAL faster.
> >
>
Should be thinking global aiki though and not just ocal
j...@fabricatorz.com
http://fabricatorz.com
On Mar 18, 2011 5:47 AM, "Jakub Jankiewicz" wrote:
> When we create better panel we'll be able to fix OCAL faster.
>
> ___
> Mailing list: https://launch
Exactly on the admin panel.
j...@fabricatorz.com
http://fabricatorz.com
On Mar 18, 2011 5:47 AM, "Jakub Jankiewicz" wrote:
> When we create better panel we'll be able to fix OCAL faster.
>
> ___
> Mailing list: https://launchpad.net/~aikiframework-devel
When we create better panel we'll be able to fix OCAL faster.
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-devel
More help : https:
Agree rejon, but a long voyage begin with short steps.
Totally. here are the priorities I see that are blocking aiki from more use:
>
> 1.) admin interface is shit.
> SOLUTION: Make mockup of new interface, allow any sysGOD/root change
> admin interfaces
>
>
> 2.) widgets are totally too compli
Totally. here are the priorities I see that are blocking aiki from more use:
1.) admin interface is shit.
SOLUTION: Make mockup of new interface, allow any sysGOD/root change
admin interfaces
2.) widgets are totally too complicated.
SOLUTION: Simplify and Type widgets.
3.) aikimarkup is inconsis
good ideas..
aiki markup need more elegance and clearness
2011/3/17 Jakub Jankiewicz
> I have another idea for AIKI markup clean up, lets remove everything
> and keep only $aiki public API and put in .
>
> and all functionality from markup move to aiki
>
> insert(10) aiki>
>
> ajax(10) aiki>
>
I particularly like the use of parameters, and giving a similar syntax
to both widget inclusion and calls to the aiki system library.
On Thu, Mar 17, 2011 at 11:31 AM, j...@rejon.org wrote:
> Definitely getting there have you looked at all the other illogical
> aikimarkup on the aiki?
>
> j..
Definitely getting there have you looked at all the other illogical
aikimarkup on the aiki?
j...@fabricatorz.com
http://fabricatorz.com
On Mar 16, 2011 9:51 PM, "Jakub Jankiewicz" wrote:
> I have another idea for AIKI markup clean up, lets remove everything
> and keep only $aiki public API an
I have another idea for AIKI markup clean up, lets remove everything
and keep only $aiki public API and put in .
and all functionality from markup move to aiki
insert(10) aiki>
ajax(10) aiki>
add() aiki>
Widgets should have parameters so instead of
(#(inherit:97|SQL NEW SELECT STATMENT)#)
If you don't read this already you should "Designing Minilanguages"
chapter in The Art of Unix Programming by Eric Steven Raymond
http://www.faqs.org/docs/artu/ch08s03.html
___
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : ai
I don't like this
sql statement
And adding for for and if is not inventing a language. It's just like C
preprocesor, This are importer because user will use AIKI not PHP. and
functions which I write about can be implemented using ruby, c, c++,etc.
Whatever run AIKI. And procedures and syntax insi
This is a great proposal! This already cleans up aikimarkup in some places.
The other thing to consider is using something like a template
language so you we can do things like:
sql statement
I still don't like the idea of creating a *another* language for
people to learn in aiki. And, to me, it
Hi.
This is my proposal for new aiki markup syntax
-
:: VARIABLES
-
All variables should look the same:
($(name)$)
($(author->uri)$)
Variable can also be simplify by replaci
49 matches
Mail list logo
