Solved: EJS templates plugin with pre-compilation support

I finalized the EJS templates plugin for CanJS with templates pre-compilation support. Sources are example are available here: https://github.com/isadovskiy/canjs-require-ejs
There are few configuration tricks, which should be done in config.js and build.js in order to make everything works. I will explain them later in readme. CanJS library sources are also tweaked a little bit to eliminate direct dependencies from window and document in the source files, which are required for EJS templates compilation.
CanJS team, if you are interesting in integration this solution into your framework, I can provide all necessary information and support.

@isadovskiy I would like to get this into CanJS.  Can I rename / cleanup the issue to make it clear that we would support plugins for building stache / mustache / ejs templates?  Thanks.

Sure! No any objections from my side.
On Wed, Feb 11, 2015 at 9:36 PM, Justin Meyer<EMAIL_ADDRESS>wrote:

@isadovskiy https://github.com/isadovskiy I would like to get this into
CanJS. Can I rename / cleanup the issue to make it clear that we would
support plugins for building stache / mustache / ejs templates? Thanks.
—
Reply to this email directly or view it on GitHub
https://github.com/bitovi/canjs/issues/491#issuecomment-73936945.

@isadovskiy are you interested in making this work similar to https://github.com/canjs/steal-stache for 3.0?  Our goal is to have these things in separate repos for 3.0, but list all of these 3rd party integrations on the homepage.
I'm going to close, but let me know and I'll create a require-stache repo.  Thanks!

@justinbmeyer at the moment we are completely switched to StealJS. So we ar not so interested in AMD support.
I also see https://github.com/canjs/steal-stache already supports AMD/RequireJS. Or am I missing anything?

Or am I missing anything?

It doesn't seem to have an actual AMD loader plugin anywhere in the source, so there's no way to, e.g., do:
define([
  "can/component",
  "stache!./my-template.stache"
], function( Component, template ) {
  return Component.extend({
    tag      : "my-component",
    template : template
  })
});

and to have that transparently work with both development builds and optimized production builds.
Maybe it's generated as part of the dist build, but I have no way to verify that, as installing the required dev dependencies with NPM to make  abuild, leads to a 100% reproducible EBUSY rename error on Windows.
There are also other issues related to loading stache templates via AMD, such as the fact that <can-import> doesn't support AMD-based module lookups. Doing that properly, i.e. , including all the AMD idioms such as relative module ID lookups; proper honoring of package, map and path directives and support for plugin loaders is non-trivial.

There is no AMD plugin in this repo, that is correct. There is a plugin a community member created but I'm having trouble finding it right now.
can-import should definitely work with Requirejs, we detect if running inside an AMD loader and call the dynamic loader: https://github.com/canjs/canjs/blob/master/util/can.js#L198-L200  This logic is tested with requirejs.

That community member would be me. ;)
I have that stache amd plugin loader working in my private repo. The public repo is a bit outdated (https://github.com/Empirion/can-stache-amd)
I've been murderously busy at work past 6 months, so I haven't even had the time to get that updated and documented. (So maybe you should reconsider my offer @rjgotten :P) If there's definite interest from someone then drop me a line. If not, updating that repository is still on my todo list somewhere in the next few weeks.

@matthewp
can-import should definitely work with Requirejs, we detect if running inside an AMD loader and call the dynamic loader: https://github.com/canjs/canjs/blob/master/util/can.js#L198-L200 This logic is tested with requirejs.

Simply using the global require entrypoint on the window is not sufficient. Like I wrote:

Doing that properly, i.e. , including all the AMD idioms such as relative module ID lookups (...) is non-trivial.

You need some intermediate logic to create a require that is local and relative to the generated module ID of the stache template that was loaded through the loader plugin.
You have to go through a two-step require-chain to get that working; first use a loader plugin engineered to retrieve a require that is rebased to the module ID passed to the loader plugin, then use that rebased require to resolve the import. I.e.
if (window.define && window.define.amd) {
  if ( parentName ) {
    window.require(["can/util/amd/rebase!" + parentName], function(require) {
      require([moduleName], function (value) {
        deferred.resolve(value);
      });
    });
  } else {
    window.require([moduleName], function (value) {
      deferred.resolve(value);
    });
  }
}

where the rebase plugin is implemented as:
define([], function() {
  var
    rootRequire = require,
    hasUndef    = "undef" in rootRequire;

  return {
    load : function(name, require, load, config) {
      // Temporary collision-free name at the same relative
      // directory level as the reference name.
      name += "#require";

      define(name, ["require"], function(require) {
        return require;
      });

      require([name], function(require) {
        hasUndef && rootRequire.undef(name);
        load(require);
      }, function(err) { load.error(err); });
    }
  }
});

@gsmeets
That community member would be me. ;)

It keeps surprising me that when either of us sits down to engineer something, we always tend to arrive at a similar solution. (One thing tho': you might want to refactor your builder to hook up the intermediate AST that the build process generated, instead of having the client reparse the template. Seems wasteful. ;-) )

You need some intermediate logic to create a require that is local and relative to the generated module ID of the stache template that was loaded through the loader plugin.

That's true, relative is currently not working with AMD modules. The Steal plugin includes the current module id (that is the id of the stache module once compiled to js), so the AMD plugin could do the same. We'd need some way to pass your own require instead of using window.require though. Very opening to collaborating with requirejs users to make sure our APIs support such a plugin.

@rjgotten

It keeps surprising me that when either of us sits down to engineer something, we always tend to arrive at a similar solution.

In this particular case I based it off of your old ejs amd version, combined with some other implementation I found floating around the interwebs. ;)

One thing tho': you might want to refactor your builder to hook up the intermediate AST that the build process generated, instead of having the client reparse the template. Seems wasteful. ;-)

I would if it actually performed better, but it doesn't. Parsing the text performed a lot better, can't remember the exact numbers, but it was > 20% perf. Discussed it with @justinbmeyer back then on gitter, and he seemed as surprised as I was. I spent a good amount of time trying to find out why, but I couldn't. The AST was just slower than the text. I still have the benchmark code somewhere shelved away...

The AST was just slower than the text.

That's slightly crazy and somewhat interesting. There's no reason that should happen from a code complexity point of view. So it has to have something to do with compiler optimizations.
I wonder if it has to do with https://github.com/canjs/canjs/blob/master/view/parser/parser.js#L21 and the fact that Function.prototype.apply is called with the array of args stored in the intermediate representation. Using apply is substantially slower than call with a fixed number of arguments, which internally desugars to the exact same operation as a regular function call and thus can be far more optimized.
I wonder what would happen when a set of intermediate functions that explicitly expands the item's args array to direct calls with the correct number of arguments for each token type is used instead.
i.e.
var arities = [
  function(handler, item, args) { return handler[item.tokenType]() },
  function(handler, item, args) { return handler[item.tokenType](args[0]) },
  function(handler, item, args) { return handler[item.tokenType](args[0],args[1]) },
  function(handler, item, args) { return handler[item.tokenType](args[0],args[1],args[2]) }
  // ...
];
function handleIntermediate(intermediate, handler){
  for(var i = 0, len = intermediate.length; i < len; i++) {
    var item = intermediate[i];
    arities[item.args.length](handler, item, item.args);
  }
  return intermediate;
}

I might just have to try that out some time. :)

Cool idea!


[FacebookBridge] permalink problem

Hey,
I'm using a feedreader-bot to get the newest posts of the rssbridge posted on a telegram channel.
But some pages doesn't post updates anymore, because the link and guid of the posts is always the same and the bot uses these to push new posts.
This is how it looks:

(From https://facebook.com/pg/Feuerwehr-Könnern-1098400606886642/posts/)
This is how it looks on other pages, which works fine:

(From https://www.facebook.com/pg/feuerwehr.guesten/posts/)
Is there any way it can be fixed? If you need more details, just let me know, and I will do my best ;-).
Thanks!

Thanks for reporting this issue! I can confirm this is happening on my machine.
Looks to me like finding the post URI is broken for posts that have a "See More" button:

Looks to me like finding the post URI is broken for posts that have a "See More" button:

Actually it doesn't, those links are actually provided by Facebook. The links are something like this:
/permalink.php?story_fbid=2118195104907182&id=1098400606886642&__xts__%5B0%5D=68.ARA0fyBcVfcEOj2OFewDp4mBqCw9GFf--I6EZ0L76B7ByluRfczd1dG2MI_DsbIG28LMUmQ_29HUkhrNzaaDjGpQ243act2igHGw9kEjuZhMXnafDXX5QJrJNjTNr7YoDR4BJPfjOxKagkjlM8q-1ChpcUNT79vI6OicfPZw5Roj1IZ_Uc1i29RXC5RpC3BHOOyLrhD-pPIYBsUM-wqG5aGdNyxzOLbHeXkkmX_qPma0ZWKiR8rIc3kuknpC02tru_bjxSe_qM6fkQSHI3bGnfBHRD0cQELcDXJ93XeNjCMhE1llgZ3TWkunHy-qqGX0PgSzkWnEiqFW5s8mtpwV81wvx1bs&__tn__=-R

Since the bridge currently filters the tokens by simply removing all query parameters, the link doesn't work anymore.

Hi,
I'm running into the same issue building a news feed in Mastodon which is collected from several Facebook pages.
All articles with a "read more" are just created with "https://www.facebook.com/permalink.php" as the link - which then does not work of course. The half of all feeds and resulting posts are broken due this.
Is there any update / chance of a fix?

I added a potential fix in #1358. Please take a look and let me know if this fixes it for you.


Clock module error (with custom format)

Hey there.
Since a few days, waybar stopped showing the clock module.
It complains about this:
[2023-12-19 08:33:03.942] [info] Using configuration file /home/id/.config/waybar/config
[2023-12-19 08:33:03.943] [info] Unable to receive desktop appearance: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
[2023-12-19 08:33:03.943] [info] Using CSS file /home/id/.config/waybar/style.css
[2023-12-19 08:33:03.948] [warning] Mapping is not an object
[2023-12-19 08:33:03.949] [info] Hyprland IPC starting

(waybar:16454): GLib-GObject-CRITICAL **: 08:33:03.994: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '73'

(waybar:16454): GLib-GObject-CRITICAL **: 08:33:03.994: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '72'
[2023-12-19 08:33:03.994] [warning] Mapping is not an object

(waybar:16454): GLib-GObject-CRITICAL **: 08:33:04.032: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '73'

(waybar:16454): GLib-GObject-CRITICAL **: 08:33:04.032: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '72'
[2023-12-19 08:33:04.032] [warning] Mapping is not an object
==> ERROR: Cannot fetch updates
[2023-12-19 08:33:04.112] [error] clock: chrono format error: no '%' at start of chrono-specs

** (waybar:16454): WARNING **: 08:33:04.239: Status Notifier Item with bus name ':1.17' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered
[2023-12-19 08:33:04.243] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:04.244] [error] clock: chrono format error: no '%' at start of chrono-specs

** (waybar:16454): WARNING **: 08:33:04.351: Status Notifier Item with bus name ':1.17' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered
[2023-12-19 08:33:04.361] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:04.479] [warning] Requested height: 24 is less than the minimum height: 32 required by the modules
[2023-12-19 08:33:04.479] [info] Bar configured (width: 1920, height: 32) for output: DP-7
[2023-12-19 08:33:04.481] [warning] Requested height: 24 is less than the minimum height: 32 required by the modules
[2023-12-19 08:33:04.481] [info] Bar configured (width: 1920, height: 32) for output: DP-5

** (waybar:16454): WARNING **: 08:33:04.515: Status Notifier Item with bus name ':1.17' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered

** (waybar:16454): WARNING **: 08:33:04.616: Status Notifier Item with bus name ':1.17' and object path '/org/ayatana/NotificationItem/nm_applet' is already registered
[2023-12-19 08:33:05.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:05.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:05.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:06.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:06.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:06.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:07.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:07.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:07.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:08.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:08.000] [error] clock: chrono format error: no '%' at start of chrono-specs
[2023-12-19 08:33:08.000] [error] clock: chrono format error: no '%' at start of chrono-specs
...

The module config is this:
  "clock": {
    "timezone": "Europe/Berlin",
    "locale": "en_GB.UTF-8",
    "format": "{:  %H:%M:%S | %d.%m.%Y}",
    "format-alt": "{: %H:%M:%S}",
    "tooltip-format": "<big>{:%Y %B}</big>\n<tt>{calendar}</tt>",
    "today-format": "{}",
    "calendar-weeks-pos": "left",
    "format-calendar": "{}",
    "format-calendar-weeks": "W{:%V}",
    "format-calendar-weekdays": "{}",
    "interval": 1,
    "on-click-middle": "kalendar"
    },

I've had this config for months, the issues only started a couple of days ago.
if I comment out the format and format-alt sections, it stops complaining, and it shows a simple clock.

I have aur/waybar-git r2429.09142fa3-1 [+27 ~0.28] [Installed: r3075.f5370fcf-1], running on aur/hyprland-git 0.31.0.r7.a0b675ec-1 [+54 ~8.03] [Installed: 0.33.1.r59.ef445093-1].
Any thoughts?

Well, I changed the format a bit (moved the icon outside of the {}, and it appears to be working fine.
  "clock": {
    "timezone": "Europe/Berlin",
    "locale": "en_GB.UTF-8",
    "format": "  {:%H:%M:%S | %d.%m.%Y}",
    "format-alt": "  {:%H:%M:%S}",
    "tooltip-format": "<big>{:%Y %B}</big>\n<tt>{calendar}</tt>",
    "today-format": "{}",
    "calendar-weeks-pos": "left",
    "format-calendar": "{}",
    "format-calendar-weeks": "W{:%V}",
    "format-calendar-weekdays": "{}",
    "interval": 1,
    "on-click-middle": "kalendar"
    },

Still got a few warnings and an error, but other than that...
[2023-12-19 09:28:09.763] [info] Using configuration file /home/id/.config/waybar/config
[2023-12-19 09:28:09.764] [info] Unable to receive desktop appearance: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
[2023-12-19 09:28:09.764] [info] Using CSS file /home/id/.config/waybar/style.css
[2023-12-19 09:28:09.769] [warning] Mapping is not an object
[2023-12-19 09:28:09.769] [info] Hyprland IPC starting

(waybar:44144): GLib-GObject-CRITICAL **: 09:28:09.803: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '73'

(waybar:44144): GLib-GObject-CRITICAL **: 09:28:09.803: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '72'
[2023-12-19 09:28:09.803] [warning] Mapping is not an object

(waybar:44144): GLib-GObject-CRITICAL **: 09:28:09.849: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '73'

(waybar:44144): GLib-GObject-CRITICAL **: 09:28:09.849: ../glib/gobject/gsignal.c:2088: type 'GtkWindow' is already overridden for signal id '72'
[2023-12-19 09:28:09.849] [warning] Mapping is not an object
==> ERROR: Cannot fetch updates
...


Add methods for calculating the size and postion of UI nodes

Objective
Users are often confused about how to calculate the size and position of UI nodes.
Solution
Implement methods on Node to calculate its size and position given its GlobalTransform.
Changelog

Added methods logical_rect and physical_rect that calculate the geometry of a UI node and return it as a bevy_math::Rect

This will be super useful for tests too.

For som reason it pulled in my changes from the UI example fix PR. Fixed, I think.


Add files via upload

Add Federal University Lokoja, Kogi State

@blessemol Pull request merged. Thank you!


i2c_master: fix len in syscalls

To match https://github.com/tock/tock/blob/master/capsules/src/i2c_master.rs#L130
Fixes #260.

Looks good, sorta strange how we only shift the write_len, and only for the write_read call and not others.

Indeed, but I suppose that this is the best we can do. Encoding both lengths in the same register will limit that to 16 bit, which might not be sufficient for some usecases (although 64k is a lot to read/write in a single operation). And shifting lengths in other calls would incur unnecessary overhead.

bors r+


Editor button

Problem description
When a user upload a tabular file and the table is selected, ODE shows the EDITOR button at the top. When clicking on it, nothing happens.

Steps to reproduce it

Open the ODE.
Upload a file.
Check main screen.

Suggested solution
Remove the Editor button.
@roll Does the button have any function?

@romicolman
For tables editing mode is always activated (so the button indicates it by color) but for other formats, it is modal selector

Ok, thanks! @pdelboca we can remove the Editor button since for the stable release we will concentrate on tabular data.

Ok, thanks! @pdelboca we can remove the Editor button since for the stable release we will concentrate on tabular data.

@romicolman , should I remove the Editor button only from the Tabular data menu? I tried with a text file and a json file and the editor is always enabled as well. Should I remove this button from everywhere or only for the menu that shows with tabular data?

@guergana please, remove it from the Tabular data menu. According to @roll this button is always active whenever the user uploads tabular data in any format, so it makes no sense.

@guergana , as we discussed during the standup meeting, please remove the Editor indicator from the app.

@guergana , as we discussed during the standup meeting, please remove the Editor indicator from the app.

Hi, I just found out the Editor button is working as a button when the file type is a chart. Should I leave the button on this case? Chart file example attached.
chart.json

@guergana when the Editor button is in purple, it is just and indicator (it does not have a particular function), so please, remove it

Please, remove the button for chart.json


Message limited to 10 characters after upgrade to DNN 9.4.1

Describe the bug
A clear and concise description of what the bug is.
After upgrading our site from DNN 9.1.1 to DNN 9.4.1, the message body text control is limited to only 10 characters. Looking at the HTML of the page, the generated textarea element has a maxlength=10 attribute, although the size of the message field is set to contain up to 1000 characters in the module settings.
Software Versions

DNN: 09.04.01
Module: 06.06.02

To Reproduce
Steps to reproduce the behavior:

Go to our site at https://www.logicaloperators.com/Contact-Us
Click on Message Body in Feedback form
Start typing. You can only enter 10 characters.
See error: examine HTML of page

Expected behavior
A clear and concise description of what you expected to happen.
Expect to be able to enter the number of characters configured.
Screenshots
If applicable, add screenshots to help explain your problem.
N/A
Error log
Note: Debug DLL's
Please replace the current extension DLL's with the debug DLL's (if these are available with the release) and reproduce the error with the debug DLL's before pasting the error log.
N/A
Paste the error log that is related to this issue.
N/A
Additional context
Add any other context about the problem here.
N/A

Wow, I am surprised this was not spotted earlier, I do see that maxLenght in the ascx. Odd.
Well there is a documented workaround to edit that file, but certainly something to fix on next release.

I didn’t really have a chance to look deeper last night, but as previously noted, I have that same version of the module running as expected on other client sites that are based on DNN 9.3.2 or lower and they all run WITHOUT generating the maxlength attribute in the resulting HTML (although the maxlength attribute is present in their Feedback.ascx files). Does the attribute get adjusted somewhere in code before the HTML is generated?
From: Daniel Valadas<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 12:53 PM
To: DNNCommunity/DNN.Feedback<EMAIL_ADDRESS>Cc: Warren Hairston<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [DNNCommunity/DNN.Feedback] Message limited to 10 characters after upgrade to DNN 9.4.1 (#51)
Wow, I am surprised this was not spotted earlier, I do see that maxLenght in the ascx. Odd.
Well there is a documented workaround to edit that file, but certainly something to fix on next release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/DNNCommunity/DNN.Feedback/issues/51?email_source=notifications&email_token=AGS4HZJH753V7277YP6Q4QDQOXYO3A5CNFSM4JAXCXAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBJPGOQ#issuecomment-542307130, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGS4HZMOVPQ2BQ6MA5RXXN3QOXYO3ANCNFSM4JAXCXAA.
This message was scanned by Logical-HES (Hosted Email Security) powered by Trend Micro

Yes, there is a setting for it. I only have a french instance right now to look at so the labels I mention here might be a bit off, but under:
Module Settings -> Form and Fields Settings -> Message maximum lenght
And I believe this overrides the maxLenght of that field. Now I still think 10 for a default is kinda short, we should at least make the default 250 or some such, 10 is ridiculous for any message.

Hi Team,
I found it was the first row that had the 10 character limit. If you hit enter, you lose the 10 character limit on the subsequent lines.

I found that my site is experiencing this as well.

Even though the setting is 1000 characters, always limited to 10. Doesn't matter if you hit enter or not in the text field, still limited.

Hi
Just installed ver. 6.6.2 and it still has the error. Any new version on its way?
I can add that the number of characters remaining is acting on the specified Max Message Length settings.

there is an open PR to fix it.

Resolved in 6.6.3 which I will publish in a minute...


STY, DOC: Fixes for log_call

Includes some minor style and doc fixes for log_call.

Looks good. Merging...


Add methods for new Deposit endpoints

https://docs.gdax.com/#deposits

I can add these and will PR

@jborseth Is this fixed?

This was handled in #314. Also related to #325.


[Bug] hdfsCannot discover a connector using option: 'connector'='starrocks'

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
The Development Mode of streamx is flink sql, the deployment method is yarn per-job, the data is written to starrocks. the flink-connector-starrocks package is uploaded on the page, click submit, execute the launch application, no error is reported, then start application, the application reports an error. Try not to upload the connector package on the page, directly put the package in the uploads directory or the flink lib directory of the same level of uploads, click submit, execute the launch application, no error is reported, then start application, the application reports an error.
streamx version 1.2.3, flink version 1.15.1, flink-connector-starrocks version 1.2.3_flink-1.15.
In addition, try to write flink sql code, submit it directly on the flink cluster using the command line, and the data is written normally.
Note: The hdfs directory configured in the application.yml file: workspace remote has been adjusted once during installation. The old directory in hdfs was deleted, and a new directory was created. After restarting the service, the new directory is empty, and there are no children in it. directories and files. When testing, the uploaded udf package can be used normally, so this problem was not taken seriously at that time.
How to solve the problem that the hdfs directory is empty and Cannot discover a connector using option: 'connector'='starrocks'
streamx 的 Development Mode 为 flink sql，部署方式 yarn per-job，将数据写入 starrocks，在页面上传了 flink-connector-starrocks 包，点击submit，执行launch application，没有报错，执行 start application任务报错。尝试不在页面上传 connector 包，直接将包放在 uploads 目录下或 uploads 同级目录 flink lib 目录下，点击submit，执行launch application，没有报错，执行 start application任务报错。
streamx 版本 1.2.3，flink 版本 1.15.1 ，flink-connector-starrocks 版本 1.2.3_flink-1.15。
另外尝试写 flink sql代码，直接在flink集群用命令行提交，数据正常写入。
备注：application.yml 文件中配置的hdfs目录：workspace remote 在安装时有过一次调整，删掉hdfs中旧的目录，创建了新的目录，重启服务后，新的目录为空，里面没有任何子目录和文件。在测试使用时，上传的udf包可以正常使用，所以此问题当时没有重视。
该如何解决hdfs目录为空，以及Cannot discover a connector using option: 'connector'='starrocks'的问题
StreamX Version
1.2.3
Java Version
No response
Flink Version
1.15.1
Scala Version of Flink
2.12
Error Exception
Caused by: org.apache.flink.table.api.ValidationException: Cannot discover a connector using option: 'connector'='starrocks'
	at org.apache.flink.table.factories.FactoryUtil.enrichNoMatchingConnectorError(FactoryUtil.java:728)
	at org.apache.flink.table.factories.FactoryUtil.discoverTableFactory(FactoryUtil.java:702)
	at org.apache.flink.table.factories.FactoryUtil.createDynamicTableSink(FactoryUtil.java:257)
	... 54 more
Caused by: org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'starrocks' that implements 'org.apache.flink.table.factories.DynamicTableFactory' in the classpath.

Available factory identifiers are:

blackhole
datagen
filesystem
kafka
print
upsert-kafka
	at org.apache.flink.table.factories.FactoryUtil.discoverFactory(FactoryUtil.java:538)
	at org.apache.flink.table.factories.FactoryUtil.enrichNoMatchingConnectorError(FactoryUtil.java:724)
	... 56 more

Screenshots
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@MonsterChenzhuo please check


Fix broken CI

Currently, JDK installation fails due to internal change in Travis.
This PR uses more robust way to install JDK when Travis update their base image.
This method (and AdoptOpenJDK) is commonly used in other Scala OSS  like https://github.com/scala/scala-collection-compat/pull/231
Also fixed the implementation to pass tests.

Scala 2.13.0 is still broken, since some dependencies does not support

Looks good. Thanks!


Mock-up beta/labs/unstable annotation for access points to services including my-services dropdown

Feature Request
Desired behaviour
Create mock-ups for how to denote this feature as highly experimental and should not be used by non-partners at this time.
Includes my-services, sitemap, docs?
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Fix Versions: Dockstore 1.8
┆Sprint: Seabright Sprint 26 Abalone
┆Issue Number: DOCK-1118

Also see SEAB-697.

Examples:
https://material.io/collections/machine-learning/barcode-scanning.html#
https://help.github.com/en/github/managing-subscriptions-and-notifications-on-github

drydock?
under construction? (maybe this implies you can't use it?)
discussion about "experimental"
don't overload tags that we use for development (alpha, beta, rc) but we can use terms that don't overlap

Preview label is in dropdown, sitemap, and header bar for my-services/services pages.


Wrong highlighting for std::atomic on gcc?

See https://godbolt.org/z/6_Wl0h
Shouldn't the movs and the mfence generated by gcc to be associated with the assignment to i?
Aside: DAK if it's an optimizer issue that gcc doesn't eliminate the memory fence completely like Clang does?

Unfortunately, the GCC assembly assigns the line to atomic_base.h (because of inlining etc) - so technically it's not wrong.
Though there is enough information in the assembly to assign it to a user sourcecode line as well. Not sure how to get that to work, but maybe we can do that.

I think this is "working as intended" -- we show the compiler's interpretation of where asm lines came from. We "know" that the xchg comes from the atomic header file, and as @partouf says that's not in the user's code, so it doesn't get highlighted. I don't know if in general we could discern the "original" code the inlined code came from, I don't think there's enough information to be 100% sure.


Add an owner different than deployment owner

Currently, the owner of the deployed contracts is assumed to be the deployer.  This ownership is required for the setup actions AutID.setNovaRegistry() and NovaRegistry.setAllowlistAddress().
This is not a best practice as the deployer should not retain any access of the protocol post-deployment.
Options

[ ] Transfer ownership post-setup
[ ] Remove access control for the setup methods

Closing for later solve.


add schema and test data as sql files

Generated using pg_dump. Test data includes approximately 100 records for each table.

@camallen I dont think we need to compress the test data, I've only included 100 records for each of the two tables and it comes out to 120KB uncompressed. If we were to include the entire dataset (~5.3 MB uncompressed) that would be a different story. Any reason we might want to include the entire dataset in the repo?

I dont think we need to compress the test data, I've only included 100 records for each of the two tables and it comes out to 120KB uncompressed.

👍

Any reason we might want to include the entire dataset in the repo?

I would put this in if / when it's available, having the ability to recreate the full db (schema & data) appeals to me

I would put this in if / when it's available, having the ability to recreate the full db (schema & data) appeals to me

Added 👍

Yup I have tested out applying the dump files to confirm that they execute as expected. Didnt try it with pg_restore but tested with the psql command \include (see docs - https://www.postgresql.org/docs/9.2/app-psql.html).

One question, are the staging / production schemas materially different? Won't they align over time and if so why do we need two different files?

The only diff between the staging and prod shema dumps is the name of the user that owns the mapping viz database on each respeective server. The pg_dump involves dumping table permissions, and it seems that table permissions for users get explicitly set within the dump. The name of the owner user on staging is mapping_viz_staging, while the name of the user on prod is mapping_viz_production, hence the need for separate files. I tried applying the schema dump from staging when I was setting up prod and ran into the user issue, so I figured we'll just need to have 2 separate schema files.
The only way around this that I can think of would be to just name the user the same thing on both envs...? i.e. not specify environment in the user name? e.g. user could be just named mapping_viz_owner. @camallen , thoughts?
Alternatively, we can just go with saving only the schema for prod? If we were to run that schema dump file on staging the necessary tables and such would still get created, just user permissions wouldn't be set.

Checkout the pg_dump --no-owner flag, https://www.postgresql.org/docs/9.5/app-pgdump.html

Wow niiiiice. Didnt even think of that. The combination of --no-owner and --no-acl does exactly what we are looking for here. Cam++


collada-dom does not compile with gcc6

Currently, collada-dom fails to compile with gcc6:
Build Configuration:
BB_VERSION        = "1.31.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-23"
TARGET_SYS        = "i586-oe-linux"
MACHINE           = "qemux86"
DISTRO            = "nodistro"
DISTRO_VERSION    = "nodistro.0"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              = "master:7e0f95bf359bc3b5bb1578024a993e184de155cd"
meta-oe
meta-python
meta-multimedia   = "master:24e387aaf78bc0f68a46abb1fab3a76364804bd1"
meta-ros          = "support-gcc6:855eebca0b754a0be65cbdc52d47a7995d01d0d4"

(...)
| [ 93%] Building CXX object dom/CMakeFiles/collada-dom.dir/src/dae/daeMetaGroup.cpp.o
| cd /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/build/dom && /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/i586-oe-linux/i586-oe-linux-g++   -DDOM_INCLUDE_LIBXML -Dcollada_dom_EXPORTS -I/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/qemux86/usr/include -I/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/collada-dom-2.4.0/dom/external-libs/minizip-1.1 -I/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/qemux86/usr/include/libxml2 -I/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/collada-dom-2.4.0/dom/include  -m32 -march=i586  --sysroot=/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/qemux86  -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0=/usr/src/debug/collada-dom/2.4.0-r0 -fdebug-prefix-map=/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux= -fdebug-prefix-map=/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/qemux86=  -fvisibility-inlines-hidden -fPIC   -fno-strict-aliasing -Wall   -DCOLLADA_DOM_SUPPORT141 -DCOLLADA_DOM_SUPPORT150 -DCOLLADA_DOM_DAEFLOAT_IS64 -DCOLLADA_DOM_NAMESPACE -fPIC  -DDOM_DYNAMIC -DDOM_EXPORT -o CMakeFiles/collada-dom.dir/src/dae/daeMetaGroup.cpp.o -c /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/collada-dom-2.4.0/dom/src/dae/daeMetaGroup.cpp
| ERROR: oe_runmake failed
| /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/collada-dom-2.4.0/dom/src/dae/daeMetaGroup.cpp: In member function 'virtual daeElement* daeMetaGroup::placeElement(daeElement*, daeElement*, daeUInt&, daeInt, daeElement*, daeElement*)':
| /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/collada-dom-2.4.0/dom/src/dae/daeMetaGroup.cpp:29:10: error: cannot convert 'bool' to 'daeElement*' in return
|    return false;
|           ^~~~~
| dom/CMakeFiles/collada-dom.dir/build.make:497: recipe for target 'dom/CMakeFiles/collada-dom.dir/src/dae/daeMetaGroup.cpp.o' failed
| make[2]: *** [dom/CMakeFiles/collada-dom.dir/src/dae/daeMetaGroup.cpp.o] Error 1
| make[2]: Leaving directory '/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/build'
| CMakeFiles/Makefile2:182: recipe for target 'dom/CMakeFiles/collada-dom.dir/all' failed
| make[1]: *** [dom/CMakeFiles/collada-dom.dir/all] Error 2
| make[1]: Leaving directory '/home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/build'
| Makefile:130: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/collada-dom/2.4.0-r0/temp/log.do_compile.8402)
ERROR: Task (/home/lukas/dev/github.com/bmwcarit/meta-ros/recipes-extended/collada-dom/collada-dom_2.4.0.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 852 tasks of which 851 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/lukas/dev/github.com/bmwcarit/meta-ros/recipes-extended/collada-dom/collada-dom_2.4.0.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

As collada-dom is needed by collada-parser and collada-urdf, and collada-dom is officially unmaintained, we do not want to spend effort making that software compile with gcc6 (unless explicitly requested by some user).

Commit https://github.com/bmwcarit/meta-ros/commit/dbc17a263d4d948cd8069e83bfa7b0a614ab7555 resolves this issue.


Email on job completion

Send an email notification to the user (also maybe support Slack notifications?) when runs complete.

https://towardsdatascience.com/automatic-notification-to-email-with-python-810fd357d89c

Closing this to disambiguate from #135 and #136


adds firebase module

adds firebase module
fix build arg

:tada: This PR is included in version 1.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


MacOS/AppKit support?

Does this package support MacOS/AppKit apps that use SwiftUI?
I am using the following example code and getting some errors:
struct AnimatedGifView: UIViewRepresentable {
    @Binding var url: URL

    func makeUIView(context: Context) -> UIImageView {
        let imageView = UIImageView(gifURL: self.url)
        imageView.contentMode = .scaleAspectFit
        return imageView
    }

    func updateUIView(_ uiView: UIImageView, context: Context) {
        uiView.setGifFromURL(self.url)
    }
}

/Users.../Views/AnimatedGifView.swift:12:25 Cannot find type 'UIViewRepresentable' in scope

/Users/.../Views/AnimatedGifView.swift:15:30 Cannot find type 'Context' in scope

/Users/.../Views/AnimatedGifView.swift:15:42 Cannot find type 'UIImageView' in scope

/Users/.../Views/AnimatedGifView.swift:16:25 Cannot find 'UIImageView' in scope

/Users/.../Views/AnimatedGifView.swift:17:34 Cannot infer contextual base in reference to member 'scaleAspectFit'

/Users/.../Views/AnimatedGifView.swift:21:33 Cannot find type 'UIImageView' in scope

/Users/.../Views/AnimatedGifView.swift:21:55 Cannot find type 'Context' in scope

struct GIFViewer: NSViewRepresentable {
    @Binding var url: URL

    func makeNSView(context: Context) -> NSImageView {
        let imageView = NSImageView(gifURL: self.url)
        imageView.imageScaling = .scaleProportionallyDown
        return imageView
    }

    func updateNSView(_ imageView: NSImageView, context: Context) {
        imageView.setGifFromURL(self.url)
    }
}


Upgrade modelerfour to 4.15.442 to resolve error generating Chat SDK

Using the latest Chat swagger we encounter the following error running autorest.swift:
FATAL: Error: Circular $ref in Model -- #/components/schemas/schemas:34 :: ["#/components/schemas/schemas:34"]
  Error: Plugin prechecker reported failure.

This has been resolved in modelerfour 4.15.442 https://github.com/Azure/autorest/issues/3630
I've confirmed when I upgrade locally the error goes away.

@tjprescott

@tjprescott

Looks good to me. I see all the tests passed

Looks good to me. I see all the tests passed


Verify visually the correctness of IO in the experiment with pre CNN

Added notebook with results in 6addf29, seems to be OK


Auto-save in new Item Submission form breaks the form

References
Major issue related to this PR: Fixes #835
Other involved issues are:
#948
#864
#884
#882
#931
Before describing the approach adopted in this PR, it is useful to summarise the problems that it directly or indirectly tries to address.
Having investigated them for a long time, it has been possible to trace the root causes of these problems.

Problems caused by the template/zero row of repeatable fields

(1) Errors cannot be displayed correctly
Even if the field is correct from an application point of view, the template row is a real form field and follows the validation rules attached to the repeatable field. For this reason we can see a section-level warning. #931

Problems caused by the repeatable field without form redrawing

(2) By clicking on ADD the repeatable field is artificially patched.
This approach forces the native flow from the used angular library and doesn't work with many of the models implemented in DSPACE, which would need custom patching logic. #948

Problems caused by the repeatable field with redraw

(3) The content in the template/zero row is deleted. #864 #884

Problems caused by lookup functionality

(4) The redraw of the form is mandatory.
The selected value is not added to the form, but a save submission is evoked. Once the data returns from the server, the form is redrawn.

Problems caused by form redraw

(5) The history of the form is deleted, bypassing the native angular logic for displaying errors, which is typically very simple to implement by exploiting the touched and pristine fields of the controls.
(6) In addition, fields edited but not saved (like during an autosave) are emptied.

At this moment all the above problems except (5), (6) and (3) (which is a side effect) are mitigated by the redraw which is extremely frequent. The more you reduce the frequency of redraw, the more these problems arise.
But it is clear that redraw in turn causes many side effects and ideally should be avoided as much as possible.
Current workaround to all this mess

Notifications to the user have been reduced to only manual saves (by clicking on the submission's footer buttons)
The Save button is only displayed as enable if there are unsaved changes.
The hasMetadataEnrichment check responsible to avoid form redraw has been reintroduced by inserting the metadata submission in the store to limit the redraw. This with the aim of reducing (3).
Unfortunately, as said, this has highlighted a number of weaknesses linked to (2). Solving these kind of problems is out of the scope of this issue, and it would be a very expensive and not very scalable job because it involves writing code for each model, and not very maintainable because in addition to having a lot of code to mantain it forces the native behavior of the library that  should be able to be upgraded easily.
We did not consider convenient to proceed with solving (3) by saving the values inserted in the first line, unless before a deep analysis and discussion with the community. The problem is the same, as well as making the store heavier it requires the implementation of specific patches for each model, an approach that is difficult to maintain and not scalable.
Since frequent or infrequent redraw is a scenario to deal with in any case, the information of touched fields has been added for the correct display of errors. But this is all made in vain by (1). Solving this problem without intervening directly on the repeatable field by rethinking it, becomes extremely difficult, unless you rewrite from scratch the error support already provided by angular (which is one of the most valuable aspects of the framework).

Moreover:
We tried to save the focused state of the section in order to postpone the form redraw which causes the emptying of populated fields and the loss of the focus field (6).
The result is that sometimes the redraw is not evoked at all as the user goes from one field to another without ever leaving the form.
It doesn't solve in any way (1) whose fix, as already stated, is expensive to implement and unmaintainable.
Ideal solution: remove the template row from the repeatable field control
Removing the template row from the repeatable fields immediately fix (1), (2), (3).
The added submission's metadata into the store reduces the redraw so that the user experience is fluid most of the time. The redraw remains in case of interaction with lookups.
Moreover
Implementing the lookup so that it directly patches the form could be more than welcome.
Leave the redraw as the only strategy in case the server actually enriches the form with additional data.
In that case a notification will be displayed to the user and it would probably be acceptable to lose the information about the touched fields and have a solution more clean and maintainable.
Checklist

[ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes TSLint validation using yarn run lint
[ ] My PR doesn't introduce circular dependencies
[ ] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[ ] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[ ] If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

@artlowel @tdonohue I've addressed all your feedbacks. I'll comment all of them in a minute.
 I screw up a bit during a rebase with the latest from main to merge a couple of conflicts, very simple indeed. I don't have anymore my local before merging so I had to rebase the only one I had after rebasing. If you have locally the previous copy of the branch you can check that differences are minimal. With this last commit I cleanup and add a missing test for a method.


HSEARCH-2244 Unify the way TermQuery for numerics are handled

@gsmet this looks good to me, I'm just surprised that you changed the existing tests instead of adding a new entity with an additional id. Maybe we already test that case somewhere else?

OK. Will bring back the test and add a new one to be on the safe side. Then I'll merge it.

Great, thanks

Merged with the additional tests. Thanks for the review!


[Bug]: IAM Role inlinePolicy conflicting with IAM RolePolicy

Is there an existing issue for this?

[X] I have searched the existing issues

Affected Resource(s)

iam.aws.upbound.io/v1beta1 - Role
iam.aws.upbound.io/v1beta1 - RolePolicy

Resource MRs required to reproduce the bug
apiVersion: iam.aws.upbound.io/v1beta1
kind: Role
metadata:
  name: crossplane-test-role
spec:
  forProvider:
    assumeRolePolicy: |-
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "AWS": "*"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
  providerConfigRef:
    name: default

apiVersion: iam.aws.upbound.io/v1beta1
kind: RolePolicy
metadata:
  name: crossplane-test-policy
spec:
  forProvider:
    policy: |
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": [
              "*"
            ]
          }
        ]
      }
    role: crossplane-test-role
  providerConfigRef:
    name: default

Steps to Reproduce

Create the Role and RolePolicy
Wait for the Role to be reconciled. Note the inlinePolicy field is now present on the role:

inlinePolicy:
    - name: crossplane-test-policy
      policy: '{"Version":"2012-10-17","Statement":[{"Action":"ec2:DescribeInstances","Effect":"Allow","Resource":["*"]}]}'

Delete the RolePolicy
Note that the inline role policy has been removed
Wait until next reconciliation of the Role
Note that the inline role policy has been recreated due to the inlinePolicy

What happened?
As no inlinePolicy was defined on the Role it should not be managing inline policies:

If no blocks are configured, Crossplane will not manage any inline policies in this resource.

Setting inlinePolicy: [] or inlinePolicy: ~ has no effect and the field is removed during reconciliation.
Relevant Error Output Snippet
No response
Crossplane Version
1.15.0
Provider Version
0.47.2
Kubernetes Version
1.26
Kubernetes Distribution
EKS 1.26
Additional Info
No response

When you see inlinePolicy set on the Role, is the field in spec.forProvider or status.atProvider?

@mbbush remembers me on your comment in https://github.com/crossplane-contrib/provider-upjet-aws/pull/933#issuecomment-1776159401

Yeah, I couldn't remember if we ever made the second fix. Sounds like probably not.

When you see inlinePolicy set on the Role, is the field in spec.forProvider or status.atProvider?

It's in both


Not found in the Package Control

I tried to install this plugin in sublimetext 3 but couldn't find it
https://packagecontrol.io/packages/Terminal

If the package isn't listed in "Package Control: Install Pacakge", then it's possible it's already installed. Please check "Package Control: List Packages".

Thanks!