On 2 April 2017 at 22:40, oldk1331 wrote:
> It's building at:
>
> https://travis-ci.org/oldk1331/fricas/builds/217926813
>
> (BTW, travis is really easy to use.)
>
> I would estimate the build + test takes over 20 minutes.
>
I see about 25 minutes. Not too bad. Looks good. Thanks.
--
You recei
It's building at:
https://travis-ci.org/oldk1331/fricas/builds/217926813
(BTW, travis is really easy to use.)
I would estimate the build + test takes over 20 minutes.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsu
> How long does it take on Travis-CI?
Still trying. Currently the problem is that the log is too big, causes travis
to abort early.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop rec
How long does it take on Travis-CI?
On 2 April 2017 at 20:38, oldk1331 wrote:
>> What is the
>> quickest and easiest way to setup a FriCAS build environment on
>> Travis-CI? Is FriCAS build time too long to make this practical? Is
>> there a way to do incremental builds, i.e. starting from a pre
> What is the
> quickest and easiest way to setup a FriCAS build environment on
> Travis-CI? Is FriCAS build time too long to make this practical? Is
> there a way to do incremental builds, i.e. starting from a previously
> compiled and saved version of the development environment?
I think Ubuntu
On 1 April 2017 at 22:02, oldk1331 wrote:
>> I would be happy to participate in
>> adding FriCAS as a "community supported language" in Travis if anyone
>> else is interested.
>
> Bill, I think the "community supported language" means that it'll be easier
> for other Spad project, while there's no
> I would be happy to participate in
> adding FriCAS as a "community supported language" in Travis if anyone
> else is interested.
Bill, I think the "community supported language" means that it'll be easier
for other Spad project, while there's not much Spad project, I think that is
unnecessary.
On 1 April 2017 at 10:46, Martin Baker wrote:
> On 31/03/17 14:08, Bill Page wrote:
>>
>> Perhaps one of the things that makes this resistance to such changes
>> seem sound is that FriCAS lacks anything approaching a comprehensive
>> test system. This makes it quite possible that changes such as w
On 31/03/17 14:08, Bill Page wrote:
Perhaps one of the things that makes this resistance to such changes
seem sound is that FriCAS lacks anything approaching a comprehensive
test system. This makes it quite possible that changes such as we
propose could have far reaching effects which are not pos
Bill Page wrote:
>
> I was thinking about how hard it might be to provide some sort of
> support for automated coverage tools. As I understand it,
> traditionally this is done through some sort of compiler
> extension/option to "instrument" the executable code so that it logs
> execution at the so
On 31 March 2017 at 14:00, Waldek Hebisch wrote:
>
> Concerning coverage, it is hard to say how good it is. If
> you mean coverage as percentage of lines of code that
> are actually executed during tests I think it is much
> higher than 10%, but lower than 100% even if you count
> only non-error
oldk1331 wrote:
>
> > Perhaps one of the things that makes this resistance to such changes
> > seem sound is that FriCAS lacks anything approaching a comprehensive
> > test system.
>
> There are virtues of FriCAS's "conservatism." At least the commit history
> is clean. I agree that test system
On 31 March 2017 at 09:38, oldk1331 wrote:
>> Yes. Do you have a plan? I think the difficulty is quite deep. The
>> resistance to these abstractions seems to be based on a difference
>> of principle rather than technical difficulty. Challenging these
>> principles is much harder than just providi
> Yes. Do you have a plan? I think the difficulty is quite deep. The
> resistance to these abstractions seems to be based on a difference of
> principle rather than technical difficulty. Challenging these
> principles is much harder than just providing a patch and showing that
> it works.
A prett
On 31 March 2017 at 08:02, oldk1331 wrote:
>> Do you consider this an argument for inclusion of this domain in
>> FriCAS?. I am also very much in favor of including Pair in FriCAS but
>> OpenAxiom also includes rep, per, Maybe, forall, introspection and
>> other language extensions.
>
> Clearly y
> Do you consider this an argument for inclusion of this domain in
> FriCAS?. I am also very much in favor of including Pair in FriCAS but
> OpenAxiom also includes rep, per, Maybe, forall, introspection and
> other language extensions.
Clearly you, me and Gabriel Dos Reis think Pair/Maybe are us
On 30 March 2017 at 07:57, oldk1331 wrote:
> Hmm, looks like OpenAxiom has already implemented Pair in 2008:
>
> https://github.com/GabrielDosReis/open-axiom/blob/master/src/algebra/mkrecord.spad.pamphlet
>
Do you consider this an argument for inclusion of this domain in
FriCAS?. I am also very
Hmm, looks like OpenAxiom has already implemented Pair in 2008:
https://github.com/GabrielDosReis/open-axiom/blob/master/src/algebra/mkrecord.spad.pamphlet
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from
I will temporarily give up my efforts to remove TBAGG from ALAGG.
Now about Pair, I have 2 reasons for it:
1. It's easier to construct ALIST.
Instead of [1,"1"]::Record(key:INT, entry:STRING) we can use pair(1,"1").
2. It allows proper '=' defined in ALAGG.
Record is a hack, it claims to have Se
> As first approximation to handling scope you would have stack of
> hashtables.
> Key is irrelevant to the problem, but typically it is String.
String is not much information. Identifier would be better. I guess the
scope stores (idenifier, value) pairs where the value type contains all
the info
Ralf Hemmecke wrote:
>
> On 03/28/2017 04:26 PM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
> >>
> >> On 03/28/2017 06:45 AM, Waldek Hebisch wrote:
> >>> To be more explicit about usefulness: suppose that you need
> >>> a lot of very similar tables. More precisely, imagine a
> >>> compiler wi
On 03/28/2017 04:26 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>> On 03/28/2017 06:45 AM, Waldek Hebisch wrote:
>>> To be more explicit about usefulness: suppose that you need
>>> a lot of very similar tables. More precisely, imagine a
>>> compiler with scopes. For each scope you want to
Ralf Hemmecke wrote:
>
> On 03/28/2017 06:45 AM, Waldek Hebisch wrote:
> > To be more explicit about usefulness: suppose that you need
> > a lot of very similar tables. More precisely, imagine a
> > compiler with scopes. For each scope you want to find
> > closest definition. I mean, I want a t
oldk1331 wrote:
>
> > I understand desire to have "fool proof" data structures.
> > However, attemps to make very safe data structures typically
> > either reduce functionality or efficiency.
>
> I'm doing so not for "safe", but for "correctness".
>
> > With current implementation scenarios like
On 03/28/2017 06:45 AM, Waldek Hebisch wrote:
> To be more explicit about usefulness: suppose that you need
> a lot of very similar tables. More precisely, imagine a
> compiler with scopes. For each scope you want to find
> closest definition. I mean, I want a table for each scope.
> Using assoc
> I understand desire to have "fool proof" data structures.
> However, attemps to make very safe data structures typically
> either reduce functionality or efficiency.
I'm doing so not for "safe", but for "correctness".
> With current implementation scenarios like above works OK.
> And other typi
oldk1331 wrote:
>
> One more argument:
>
> Like there are SetAgg/MultisetAgg, Dictionary/MultiDictionary,
> if you insist that AlistAgg is "table like", fine, but AlistAgg is
> not TableAgg, maybe "MultiTableAgg".
That would be different thing, you would have change implementation
and signatures
oldk1331 wrote:
>
> TBAGG is KeyedDictionary is Dictionary:
> ++ A dictionary is an aggregate in which entries can be inserted,
> ++ searched for and removed. Duplicates are thrown away on insertion.
>
> So ALAGG doens't satisfies requirement of this structure.
Note "on insertion". So 'insert!'
One more argument:
Like there are SetAgg/MultisetAgg, Dictionary/MultiDictionary,
if you insist that AlistAgg is "table like", fine, but AlistAgg is
not TableAgg, maybe "MultiTableAgg".
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra syste
> This patch for me looks as step back. First, proposed Pair
> is largely redundant. In practice Record serves well the
> same purpose. In fact, unlike proposed Pair records have
> user setable fields names instead of meaningless 'first' and
> 'second' so Record from user point of view is closer
oldk1331 wrote:
>
>
> (This an early version patch, many things are still lacking.)
>
> I want to do some big changes, this patch is a proof of concept:
>
> 1. Introduce a new domain Pair, as an abstraction over Record
> with 2 fields.
>
> 2. Introduce Pair to AlistAgg. (and TableAgg, not done
On 03/27/2017 01:03 PM, oldk1331 wrote:
> +pair(x, y) == [x, y]
If I were a compiler, I would not see a specification for x and y, so I
take the freedom to create a local function
pair(x: Integer, y: Integer): List Integer == [x, y]
and leave the signature pair: (A, B) -> % unimplement
(This an early version patch, many things are still lacking.)
I want to do some big changes, this patch is a proof of concept:
1. Introduce a new domain Pair, as an abstraction over Record
with 2 fields.
2. Introduce Pair to AlistAgg. (and TableAgg, not done in this patch.)
3. Remove TableAgg f
33 matches
Mail list logo