Hi Ned - this sounds like a great project.
I had a look over the Pinecone library and really liked the clean markup and good organisation. It's great
that this collection of components has already been validated through use in several projects.
I've long felt that there is a gap in our lineup wi
On 10/11/2020 14:43, Giovanni Tirloni wrote:
Hi Justin,
I looked for the plugins in the marketplace but I was only able to install the
following:
We'll probably have to re-apply to get open-source licenses for them since
they're paid.
Additionally, I couldn't find a way to transfer our exi
I like the idea of the redirects + load balancer and for me, given I am now a family man, the weekend is a
perfectly fine time for that migration work. Thanks so much for looking into it!
Cheers,
Antranig
On 09/11/2020 22:51, Giovanni Tirloni wrote:
One alternative that I've been researching i
Cheers, this is brilliant work and great to reduce our dependence on
Jenkins. Does the CI job run automatically for every update to a PR, or
is there some equivalent of the old "ok to test" system?
On 19/06/2020 13:31, Giovanni Tirloni wrote:
Hi Tony,
I translated the Jenkins configuration th
No worries, I will reprioritise this crash which I had on my radar
before I relocated to a half-wrecked farmhouse where the running water
is supplied through an upturned milk crate. It should be pretty easy at
least to patch Kettle so the concurrency failure doesn't crash the
server, although u
It would be a terrible idea to migrate our issues to Github issues. As well as all of the work implied onto
our community, which is much less well resourced than the Spring Framework, we face the burden of rewriting
all the links to JIRAs which are held in numerous places in other tools and resou
I wondered how it worked, and appears to be a form of "mechanical hash
function" -
https://toool.nl/images/e/e5/The_New_Master_Lock_Combination_Padlock_V2.0.pdf
"The number of combinations is unlimited, but the number of
mechanically-possible states is markedly finite: 7,501 to be exact. mh
li
Yes, what you've written is OK, although a shallow copy will be
perfectly fine that is,
curUnsavedChanges = that.model.unsavedChanges.concat([{description:
description}]) or so.
Yes, there will indeed be new dedicated change types as planned at
https://issues.fluidproject.org/browse/FLUID-3504 -
I'm happy to report the merge of a major and significantly useful pull request
https://github.com/fluid-project/infusion/pull/822 from Tony Atkins which adds long-awaited and much needed
code coverage and testem drivers to Infusion. As well as providing amalgamated coverage reports derived from
Cheers Danail - yes there is indeed the forceCache option but this only really deals with part of the
problem caused by I/O being scattered around the design. I appreciate that you are seeking a neater design
where the I/O that a widget demands is located together with it in a self-contained way
Cheers for these good questions, Danail.
For the first question(s), we generally favour having markup in its own file when i) there are more than a
couple of tags involved, ii) the markup may be worked on by different teams with different skills, iii)
there seems to be some reuse potential for
Thanks for these questions Georgi - we'll try to discuss this a bit further with Justin later today but here
are some answers to these specific questions.
The Infusion renderer has been deprecated for a while, since it was designed some time ago in a rather
different technological environment and
Just before Christmas, Tony Adtkins and I ran into a very unfortunate cache corruption issue which seems to
affect both yarn and npm, in the case where you are working with multiple versions of Infusion (or indeed,
one imagines, any project) throughout a tree which at some sites is sourced via np
One outcome from our community meeting on 21st Dec 2016 looking forward to Infusion beyond the 2.0 release
was a proposal that we change our system for numbering dev releases of Infusion. Until now we have operated
a policy that the version number of Infusion in trunk is derived from the *next* v
Thanks, Alan - this is really useful research. I was expecting that we
would run into such roadblocks as we tried to get to grips with this
space - for example, making a monorepo out of gpii/windows and
gpii/universal. We will doubtless have to get our "git-fu" up to a level
it hasn't received
Last month a few of us had an updated conversation about where our
thinking about how to modularise our repositories had reached. The notes
were taken in a "GPII pad" and weren't more widely circulated - so I
took the opportunity now to wikify them and update our ancient page on
Modularisation
Infusion has been the first of our libraries to be updated to the new, shareable ESLint configuration
(thanks to Justin Obara for this great work). Our .eslintrc files have been traditionally cut and pasted
across projects, which made for a lot of slop when adjustments needed to be made to the ru
ranig
On 11/09/2016 23:55, Antranig Basman wrote:
Hi - I would like to nominate Simon for commit access to Fluid's repositories.
The procedures and
responsibilities for this are listed on this page:
http://wiki.fluidproject.org/display/fluid/Process+for+Granting+Commit+Access
Simon has co
Hi - I would like to nominate Simon for commit access to Fluid's
repositories. The procedures and responsibilities for this are listed on
this page:
http://wiki.fluidproject.org/display/fluid/Process+for+Granting+Commit+Access
Simon has consistently shown sound judgement, due care and a deep
i
https://github.com/fluid-project/infusion/pull/730 and
https://github.com/fluid-project/infusion/pull/731 should go in before
the release, but otherwise I think it could happen at any time.
It would be nice to be able to move to a cycle where releases could be
made whenever convenient. A big b
This week's Infusion-related questions from Mike Skirpan at
https://github.com/wannabeCitizen/data-dashboard/blob/master/docs/journal/06-28-2016.md
> When you register a listener, does the function it calls by
> default pass the component that is listening for the event? I'm
> noticing that often
At his blog at https://github.com/wannabeCitizen/data-dashboard/blob/master/docs/journal/06-15-2016.md our
GSoC student Mike Skirpan has asked some chartAuthoring and Infusion-related questions which I will answer
inline here:
Registering the component's namespace. When to use it? [eg,
https:
https://github.com/fluid-project/infusion/pull/701
This merge, done 6 days ago, has broken our tests. This can be seen at
http://build.fluidproject.org/infusion/tests/framework-tests/core/html/ModelTransformation-test.html
As well as this not being caught by the reviewer for some unaccountable r
Hi Jon - yes, this is really important work - since we are rapidly gaining new repos that need to take
advantage of a docs platform. The refactoring certainly needs to be done so that our rendering and
publishing workflow can be reused.
I'm not sure about item 1, with respect to decoupling ours
It appears that our front-runner plan for modularizing Infusion and other "overly large" repositories such
as Kettle has come of age, been named and supported by others in the community. A great vindication for
"masterly inaction" since this is now work that we don't need to spearhead ourselves.
Cheers, Alan - this is a really important and strategic issue and I wanted to thank you for organising the
discussion in such a clear way.
I think the basic plan here is highly desirable - to move towards npm infrastructure and package.json as our
central solution for managing JS dependencies,
s sort of thing.
Colin
On Feb 8, 2016, at 11:55 AM, Antranig Basman
wrote:
I think it is a great idea. However, it does seem that they want a running subscription fee ($14
plus $7/user/month) to create an npm organisation. I know from experience that this is not
something we can pay for
I think it is a great idea. However, it does seem that they want a running subscription fee ($14 plus
$7/user/month) to create an npm organisation. I know from experience that this is not something we can pay
for from IDRC funds. Also, it seems that the scope "fluid" is taken already, although we
Sorry for the error - the meeting is actually scheduled for 4pm
TOMORROW, that is Tuesday 19th.
Cheers,
Antranig
On 18/01/2016 18:47, Antranig Basman wrote:
Here are the wikified notes of today's meeting, taken from the Google Doc -
https://wiki.fluidproject.org/display/fluid
Here are the wikified notes of today's meeting, taken from the Google Doc -
https://wiki.fluidproject.org/display/fluid/GPII+Preferences+Edge+Proxy+Refinement+I
We will meet to further refine our understanding of this work and
continue working through Simon's demo workflow at 4pm on Thursday.
This morning we had an edifying and productive meeting planning our strategy for integrating the GPII prefs
server together with deployments of preference editors on static and other sites. The minutes are wikified
below - we will meet again at 12 EST on Monday to work on task item 1 below, deter
s might also promote some opportunistic exploration
of using them in the intervening time.
Cheers,
Antranig
On 25/11/2015 20:34, Colin Clark wrote:
Antranig,
On Nov 25, 2015, at 2:24 PM, Antranig Basman
wrote:
"Minified builds aren't intended for development. They're desi
own, as well as doing them an unnecessary disservice, we also increase
the risk of incurring support problems that we're not equipped to handle.
Cheers,
A
On 25/11/2015 18:55, Colin Clark wrote:
Hi Antranig,
On Nov 25, 2015, at 1:48 PM, Antranig Basman
wrote:
If we don't have t
I have read ahead in this thread (up to the current time) but thought
I'd reply to the original message since it contains the relevant
transcripts.
I'm wondering what the source of surprise is, "that the code was
actually different" - isn't this exactly the behaviour we expect from a
compress
34 matches
Mail list logo
