NTR: aerial mycelium formation

A scan of Google search results and publications refer to "aerial mycelium" with "formation" and not "development." Aerial mycelia are distinct from vegetative mycelia. In some fungal species, spores develop from the tips of aerial mycelia.
NTR:  aerial mycelium formation
Def:  Growth of hyphae in an upward or outward direction from the surface of the substrate, and from which propagative spores develop in or on characteristic structures that are distinctive for various fungal species.
PMID:12832397
Note that this term may be used to replace the ambiguous term GO:0043581 mycelium development

Note for self: also see http://wiki.geneontology.org/index.php/Ontology_meeting_2016-09-22#FAO_update and https://github.com/obophenotype/cell-ontology/issues/447

Hi @dianeoinglis ,
Were you planning to add a FAO term for ‘aerial mycelium’, under FAO:0000011 ‘mycelium’?
If yes, I’ll use the new FAO term for the logical definition of GO:NEW 'aerial mycelium formation', see http://wiki.geneontology.org/index.php/Ontology_meeting_2016-09-22#FAO_update.
If not, or if it’s more urgent to have the GO term so @tberardini  can send the obsoletion notice for https://github.com/geneontology/go-ontology/issues/12613, I’ll add the GO term and we’ll define it logically later on.

Yes. Good idea. to add "aerial mycelium" to the FAO under "mycelium" as you suggest.
I need to communicate with @cmungall about editing the FAO-obo on a PC that I'm using while my Mac laptop is in repair. Would it work if I assigned the next FAO term ID and definition in a spreadsheet and formally edit the FAO in the near future?
I think it fine to send out the obsoletion notice for "mycelium development" and include a description of the three terms that can be used as replacements.
The term "substrate mycelium formation" was requested and approved of by Martin Urban at PhiBase. I will create a NTR for this term asap so that you can include it on the list of proposed replacement terms.

On 13 Oct 2016, at 5:09, Diane O Inglis wrote:

I need to communicate with   @cmungall   about editing the FAO-obo
on a PC that I'm using while my Mac laptop is in repair. Would it work
if I assigned the next FAO term ID and definition in a spreadsheet and
formally edit the FAO in the near future?

I am the worst person to advise on using github with a PC (although
Protege or OE should work fine). Do we have a backup person? If it's
just a handful of terms over a short term one of use can add.

Hi Chris,
For now just a few terms can be added but after looking at some of the
parentage and definitions there are quite a few terms that should be
updated or modified, or moved under a different parent. I will create
tickets for each proposed change. Those can wait.
Another question...is it best to make a pull request then merge or how is
modification and saving to the repository best handled?
Thanks!
Diane
On Thu, Oct 13, 2016 at 4:35 AM, Chris Mungall<EMAIL_ADDRESS>wrote:

On 13 Oct 2016, at 5:09, Diane O Inglis wrote:

I need to communicate with   @cmungall   about editing the FAO-obo
on a PC that I'm using while my Mac laptop is in repair. Would it work
if I assigned the next FAO term ID and definition in a spreadsheet and
formally edit the FAO in the near future?

I am the worst person to advise on using github with a PC (although
Protege or OE should work fine). Do we have a backup person? If it's
just a handful of terms over a short term one of use can add.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/geneontology/go-ontology/issues/12659#issuecomment-253488665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMHbqaBFTWSi-UulREhm3tCOlnABY26Rks5qzheIgaJpZM4J8H5A
.

Hi @dianeoinglis,
I added ‘aerial mycelium formation’ as follows:
[Term]
id: GO:0097736
name: aerial mycelium formation
namespace: biological_process
def: "The process by which hyphae grow in an upward or outward direction from the surface of the substrate; from there, propagative spores develop in or on characteristic structures that are distinctive of some fungal and bacterial species. The species that form an aerial mycelium develop conidiophores at the ends of the aerial hyphae." [GOC:di, PMID:12832397]
synonym: "aerial hyphal growth" RELATED []
synonym: "fertile mycelium formation" RELATED []
is_a: GO:0019954 ! asexual reproduction
is_a: GO:0048856 ! anatomical structure development
relationship: only_in_taxon NCBITaxon_Union:0000020 ! Fungi or Bacteria
I’m not sure that the parentage is fully correct.

[ ] Should ‘aerial mycelium formation’ be is_a ‘anatomical structure formation involved in morphogenesis’ instead of ‘anatomical structure development’?

Also, when you create the FAO term for ‘aerial mycelium’, please post its ID here, and

[ ] I will add a logical axiom to GO:0097736 ‘aerial mycelium formation’

Lastly, may I please suggest that discussion on FAO terms themselves and editing practices is moved to a separate repository if there’s one, to avoid confusion? :-)
Thanks,
Paola

Note for self: based on the discussion in https://github.com/geneontology/go-ontology/issues/12745, I think the current parentage of 'aerial mycelium formation' is fine. I am setting this ticket to 'pending' while waiting for the FAO term for ‘aerial mycelium’.

Wrapping up, the only action item left for this ticket is

[ ] when a FAO term is created for ‘aerial mycelium’, its ID can be used to add a logical axiom to GO:0097736 ‘aerial mycelium formation’.

Hi @ukemi, another one -
I’ve completed my tasks for this ticket, and the only thing left to do (low priority) is to add a logical definition if/when a FAO term is created (details above). Therefore I will now unassign myself from this ticket. However, since unassigned tickets tend to fall through the cracks when they’re not recent, I will assign it to you (as main ontology editor at this stage), and you can then hand it over to others if and as appropriate. Thanks.

@dianeoinglis , I don't see this term either.

This GO term is awaiting the creation of the FAO term, 'aerial mycelium.' Will be done soon.

@mah11 an you please add the term in FAO?
Thanks, Pascale

watch https://github.com/obophenotype/fungal-anatomy-ontology/issues/11

https://github.com/geneontology/go-ontology/pull/16592


Sharing is caring2022 bretto87

Category

[x] New Sample

What's in this Pull Request?
Power Apps Calendar Component

Thank you @bretto87 ! Much appreciated!


ROX-14063: expand collection proto to include matching type

Description
Expand Collection proto to include a match type enum. Utilize the match type when creating the query from a given collection object. Verify that label matching rules only use exact matching.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/test all

/test all

/test all

Works well for me from a UI side testing latest roxbot build 3.73.x-370-g82a69065f0 👍


Tables with CJK characters do not align

👓 What did you see?
When having CJK characters in table, table is not aligned after formatting.
✅ What did you expect to see?
The table should be aligned, one cjk character should be calculated as two spaces instead of one.
📦 Which tool/library version are you using?
cucumber vscode extension, 1.2.8
🔬 How could we reproduce it?
📚 Any additional context?

expected:

actual:

This text was originally generated from a template, then edited by hand. You can modify the template here.

btw. The "Cucumber (Gherkin) Full Support" extension just do the right thing

Thanks so much for contributing this issue @pkufranky! 🎉 A fix has been implemented in the gherkin formatter package and will be available in a coming release once we propagate the change to this extension. Welcome any further contributions - thanks again!


Corrected typo

There was a typo in the usage instructions which causes the thingy to not work

What specifically goes wrong with sudo insmod uwurandom.ko, and have you tested and confirmed that your change fixes it? insmod is supposed to work with .ko files.

wait shit i read it wrong :skull:


EEbus: let loadpoint rewrite currents on connection

/cc @DerAndereAndi

Ok. Got it. This would already help I think. I would add events to ev connects/disconnects later in another PR to cover the scenario where this happens within an interval.


VLIVE (vlive.tv) subtitles support for videos and posts

Checklist

[X] I'm requesting a site-specific feature
[X] I've verified that I'm running yt-dlp version 2022.06.29 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
United States
Example URLs
https://www.vlive.tv/video/274092
https://www.vlive.tv/post/0-29172771
Provide a description that is worded well enough to be understood
Videos and posts from vlive.tv will download, but subtitles don't seem to be discovered for downloading.
Many videos have English, Spanish, Japanese, Korean subtitles, among other languages.
Expectation is that the subtitle features ['--write-sub', '--embed-subs', '--sub-lang', 'en'] work for vlive.tv videos.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://www.vlive.tv/post/0-29172771']
[debug] Home config "yt-dlp.conf": ['--write-sub', '--embed-subs', '--sub-lang', 'en', '--ignore-errors', '--continue', '--no-overwrites', '--download-archive', 'progress.txt', '--ffmpeg-location', 'C:\\Users\\chiarng\\ffmpeg\\bin']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.06.29 [9d339c4]
[debug] Python 3.10.5 (CPython 64bit) - Windows-10-10.0.22000-SP0
[debug] Checking exe version: "C:\Users\chiarng\ffmpeg\bin\ffmpeg" -bsfs
[debug] Checking exe version: "C:\Users\chiarng\ffmpeg\bin\ffprobe" -bsfs
[debug] exe versions: ffmpeg 5.0.1-essentials_build-www.gyan.dev (setts), ffprobe 5.0.1-essentials_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.06.15, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Loading archive file 'progress.txt'
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
[debug] Downloading _update_spec from https://github.com/yt-dlp/yt-dlp/releases/download/2022.06.29/_update_spec
Latest version: 2022.06.29, Current version: 2022.06.29
yt-dlp is up to date (2022.06.29)
[debug] [vlive:post] Extracting URL: https://www.vlive.tv/post/0-29172771
[vlive:post] 0-29172771: Downloading post JSON metadata
[debug] [vlive] Extracting URL: http://www.vlive.tv/video/283595
[vlive] 283595: Downloading officialVideoPost JSON metadata
[vlive] 283595: Downloading inkey JSON metadata
[vlive] 283595: Downloading JSON metadata
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), acodec, filesize, fs_approx, tbr, vbr, abr, asr, proto, vext, aext, hasaud, source, id
[debug] Default format spec: bestvideo*+bestaudio/best
[info] 283595: Downloading 1 format(s): avc1_1080P
[debug] Invoking http downloader on "http://globalv.p.naverrmc.edgesuite.net/c/read/v2/VOD_ALPHA/global_v_2022_05_16_161/distribution_pathfinder_pf2448100_bac939f2-d4ed-11ec-bd34-a0369ffdada8.mp4?__gda__=1656844769_5f76cae0e425c66f6beea1f834404a7a"
[debug] File locking is not supported. Proceeding without locking
[download] Destination: 헌이 향수 공방 🌹 [283595].mp4
[download] 100% of 414.03MiB in 01:07
[EmbedSubtitle] There aren't any subtitles to embed
[debug] Adding to archive: vlive 283595

The language code is wrong. See --list-subs for the correct code

Thanks!! I made it work with your suggestion, woo!


New package: NomanDhoni.BlinkEye version 1.4

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Verify:

The application apparently doesn't have further UI - from the project page:

Usage

The app will display a full-screen popup every 20 minutes with a 20-second countdown to remind you to look away and reduce eye strain.

Click the "Skip Reminder" button to close the popup for the current session.

Audio will be automatically muted during reminders and restored afterward.

Verify:

The application apparently doesn't have further UI - from the project page:

Usage

The app will display a full-screen popup every 20 minutes with a 20-second countdown to remind you to look away and reduce eye strain.

Click the "Skip Reminder" button to close the popup for the current session.

Audio will be automatically muted during reminders and restored afterward.

That's correct


custom token picture for migration pop-up

handle an error if token picture does not exist for migration section
https://atayen.atlassian.net/jira/software/c/projects/SW/boards/1?modal=detail&selectedIssue=SW-3497&assignee=61a78f08f24150007215be93


deep path's don't work

$.key.object
or any variation
$.key.object+
does not work on simple json :
{"key": {"object:"value"} }

For such a JSON you should specify root path: path and name type as an object. (at this moment there are 2 scrape types value or object)
jsonexporter.yml
- name: key
  path: $.key.*
  type: object
  values:
    object: $.object

Noob question. Is there a way to extract substring from a key?
{
    "status/5xx": 1234
}

- name: finagle_http_status
  path: $.status/(.*)
  labels:
    status: $1

doesn't extract the status value

This shouldn't be an issue an issue with the new JSONPath library introduced in version 0.3.0. Please re-open this issue if the problem still persists.


Broken on SOD PTR

I have disabled all other addons. This only happened a certain update (I want to say 10.2 but I'm not 100% sure). I already tried reinstalling and deleting saved variables etc.

Misaligned action bars, module options are not selectable

XP bar in the middle of my screen that I can't move
Also chat says v0.10.2 but I'm on v0.10.3 according to curseforge

Hey,
I'll install the PTR and take a look.
(Version in the chat might be wrong because I manually uploaded a small bug fix and maybe didnt change the version in the .toc file)

Modules/Actionbar.lua
line 2851
Module.ChangeMicroMenuButton(SocialsMicroButton, 'GuildCommunities')

comment that out, so
line 2851
--Module.ChangeMicroMenuButton(SocialsMicroButton, 'GuildCommunities')

Than it seems to work (They changed to the new guild frame).
But there are still errors left, but they dont seem to make much sense, needs more investigation.

I fixed it!
Everything should work fine, but if you want the errors gone now:
delete 'Blizzard_Collections' from  '## OptionalDeps:' in DragonflightUI.toc

v0.11 (with those fixes ) on its way to Curseforge.


Replace emoji_codes.js, pygments_data.js with JSON modules

webpack optimizes JSON modules using JSON.parse("{…}"), which is faster than the normal JavaScript parser.
Update the backend to use emoji_codes.json too instead of the three separate JSON files.
Testing Plan: test-js-with-node, run-dev

@andersk Thanks for making this change!  I like the double win--not only will it be faster for the machine, but it's less code for the humans to read.
I think when Harshit wrote the original node tests, there were slightly different forces at play that led him to override emoji_codes, but now I think the tests will be simpler if we just use real data.  So I propose squashing this into your commit:
-    const orig_emoji_codes = Object.assign({}, emoji_codes);
-    Object.assign(emoji_codes, {
-        name_to_codepoint: {
-            '+1': '1f44d',
-        },
-        codepoint_to_name: {
-            '1f44d': 'thumbs_up',
-        },
-    });
-    canonical_name = emoji.get_canonical_name('+1');
-    assert.equal(canonical_name, 'thumbs_up');
+    canonical_name = emoji.get_canonical_name('thumbs_up');
+    assert.equal(canonical_name, '+1');

-    emoji.active_realm_emojis = {
-        '+1': 'TBD',
-    };
     canonical_name = emoji.get_canonical_name('+1');
     assert.equal(canonical_name, '+1');

+    canonical_name = emoji.get_canonical_name('airplane');
+    assert.equal(canonical_name, 'airplane');
+
     blueslip.set_test_data('error', 'Invalid emoji name: non_existent');
     emoji.get_canonical_name('non_existent');
     assert.equal(blueslip.get_test_logs('error').length, 1);
     blueslip.clear_test_data();
-    Object.assign(emoji_codes, orig_emoji_codes);

It's possible we should do the same for the pygments data in the typeahead tests, although I think the pygments data might be a little more churnful.  Then again, it probably wouldn't kill us if some change to the pygments data broke the unit test.  We'd find it in CI, and it would presumably either be a simple test fix or expose something about the data that we should account for.

Yeah, that’s even better. Squashed.

Also fixed the reactions test to use the real emoji_codes data. (It just needed some character values corrected.)

LGTM.  Thanks for the follow-up fixes with the reactions tests.

This is great, merged, thanks @andersk!


searching for a simple mark.js exemple with .html + .js + .css

Hi,
I just discover this javascript package and i want to try it.
I'm looking for a javacsript component for searching / highlighning text in wbe page and this one seems amazing !
I'm new in javascript, i've download the package on github but didn't succeed to make it works with a simple exemple agregating the differents componenets .html + .js + .css.
May some one help me ?
Thanks a lots, regards

Hello @Olivier-Lakoue
There are a couple of examples on the website, please take a look: https://markjs.io/#examples

Thanks for your help, i've found a complete exemple.
Your work is great !!!


IndexError when reading empty MultiLineString

Expected behavior and actual behavior.
Similar to #837, shapely fails to load MultiLineString objects with empty geometries
This in fact raises an IndexError when trying to access the first set of coordinates:
Steps to reproduce the problem.
This problem can be reproduced by loading an empty geometry, for example:
import geopandas as gpd
features = [{'type': 'Feature', 'id': '21', 'properties': {'valid':'true'}, 'geometry': {'type': 'MultiLineString', 'coordinates': [[[1.0, 2.0], [1.0, 3.0]]]}}, {'type': 'Feature', 'id': '22','properties': {'valid':'false'},  'geometry': {'type': 'MultiLineString', 'coordinates': [[]]}}]
gpd.GeoDataFrame.from_features(features[:1]) # this will pass
gpd.GeoDataFrame.from_features(features[1:]) # this will fail

The problem sits in these lines https://github.com/Toblerity/Shapely/blob/e4afcf5d0b497c407ba8a1115e423628cbbfe337/shapely/geometry/multilinestring.py#L121-L129
In particular there is no effective test for empty geometries
Operating system
Windows 10
Shapely version and provenance
'1.6.4.post1' installed using conda

@alessioarena we aren't supporting versions < 1.7 anymore. Can you reproduce this with version 1.7.0?

yes
import Python 3.6.10 | packaged by conda-forge | (default, Apr 24 2020, 16:44:11)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shapely
>>> shapely.__version__
'1.7.0'
>>> import geopandas as gpd
>>> gpd.__version__
'0.8.0'
>>> features = [{'type': 'Feature', 'id': '21', 'properties': {'valid':'true'}, 'geometry': {'type': 'MultiLineString', 'coordinates': [[[1.0, 2.0], [1.0, 3.0]]]}}, {'type': 'Feature', 'id': '22','properties': {'valid':'false'},  'geometry': {'type': 'MultiLineString', 'coordinates': [[]]}}]
>>> gpd.GeoDataFrame.from_features(features[:1]) # this will pass
                                            geometry valid
0  MULTILINESTRING ((1.00000 2.00000, 1.00000 3.0...  true
>>> gpd.GeoDataFrame.from_features(features[1:]) # this will fail
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/flush5/are014/anaconda/envs/pyAODN/lib/python3.6/site-packages/geopandas/geodataframe.py", line 405, in from_features
    "geometry": shape(feature["geometry"]) if feature["geometry"] else None
  File "/flush5/are014/anaconda/envs/pyAODN/lib/python3.6/site-packages/shapely/geometry/geo.py", line 42, in shape
    return MultiLineString(ob["coordinates"])
  File "/flush5/are014/anaconda/envs/pyAODN/lib/python3.6/site-packages/shapely/geometry/multilinestring.py", line 52, in __init__
    self._geom, self._ndim = geos_multilinestring_from_py(lines)
  File "/flush5/are014/anaconda/envs/pyAODN/lib/python3.6/site-packages/shapely/geometry/multilinestring.py", line 123, in geos_multilinestring_from_py
    N = len(exemplar[0])
IndexError: list index out of range
>>>

I can't reproduce this on the maint-1.7 branch. It was solved post-1.7 release by #852. I added some test cases in #949 to prove it.

Thanks @tomplex !

Resolved by #935.


Check max for topic partitions

From https://github.com/jlandersen/vscode-kafka/pull/60#discussion_r551864012
We should prolly limit the max value for the number of topic partitions. Looks like 10 seems to be the max recommended amount, So setting 100 as a limit might be fine. @jlandersen WDYT?
Kafka clusters seem limited to 200K partions overall, if anything that should be the hard limit.

cc @fbricon  as he mentioned it in the PR.
I think it's good with the validation of positive number for now. I don't think we should take as stand on what is an appropriate amount of partitions. I've worked with situations that made topics go from just a handful to a few hundred partitions for various reasons.  Going above any hard limit imposed by the cluster, I would assume would return an error for the request similar to setting an invalid replication factor in case you don't have enough brokers to honor and be handled/displayed automatically. I think it's good as-is.

cc @fbricon  as he mentioned it in the PR.
I think it's good with the validation of positive number for now. I don't think we should take as stand on what is an appropriate amount of partitions. I've worked with situations that made topics go from just a handful to a few hundred partitions for various reasons.  Going above any hard limit imposed by the cluster, I would assume would return an error for the request similar to setting an invalid replication factor in case you don't have enough brokers to honor and be handled/displayed automatically. I think it's good as-is.

Thanks @jlandersen for your feedback.
@fbricon what do you think about that?

Thanks @jlandersen for your feedback.
@fbricon what do you think about that?

@fbricon I think we can close this issue, no?

I close the issue because it seems we should not manage this usecase https://github.com/jlandersen/vscode-kafka/issues/65#issuecomment-765996789


misc: Update license

Update license.
We also change the license for docs/conf.py from the Q-CTRL one to the Apache one.

Thanks @leoadec, looks like its on our list but not in place just yet


PageView widget does not work with screen reader after navigating away and back

The PageView widget becomes not usable in screen reader mode when doing the below steps.
Steps to Reproduce

Run flutter create bug.
Update the main.dart with the contents of this gist: https://gist.github.com/rami-a/e1905d995c673a1e92f4eaf3aaa88571
Run the app on device and enable screen reader (talkback/voiceover)
Navigate to the last item in the page view
Double tap to navigate to a new route
Tap back button to go back
Now try to navigate through the page view and you will be stuck on the only visible element and unable to see the other elements.

Expected results:
Being able to use the screen reader to navigate through all of the PageView items
Actual results:
Stuck on the currently visible PageView item and unable to navigate through the rest
See video for details:
https://user-images.githubusercontent.com/2364772/122081386-0d4be700-cdcd-11eb-8f45-740e56cc1772.mp4

Logs
[✓] Flutter (Channel master, 2.3.0-17.0.pre.366, on macOS 11.3.1 20E241 darwin-x64, locale en-US)
    • Flutter version 2.3.0-17.0.pre.366 at /Users/raboughanem/Development/flutter
    • Upstream repository git@github.com:rami-a/flutter.git
    • Framework revision db930ba32f (14 hours ago), 2021-06-14 18:29:03 -0700
    • Engine revision e1d2d4b264
    • Dart version 2.14.0 (build 2.14.0-210.0.dev)

Hi @rami-a, thanks for filing the issue.
I am unable to reproduce the issue on android on iOS with master 2.5.0-7.0.pre.129 and stable 2.2.3.
Kindly see attached videos.
Caveat: I am not well-versed in the usage of the accessibility mode on either devices, so if my reproduction is wrong kindly let me know and point me in the right direction. If the reproduction is to your satisfaction and you believe that the issue has been solved, kindly leave a comment and I'll close the issue, or you can do that as well.
Thank you.
android.mp4.zip
ios.MOV.zip

flutter doctor -v
[✓] Flutter (Channel master, 2.5.0-7.0.pre.129, on macOS 11.5.1 20G80
    darwin-arm, locale en-GH)
    • Flutter version 2.5.0-7.0.pre.129 at /Users/nexus/dev/sdks/flutters
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 29c089c2ed (80 minutes ago), 2021-08-18 01:37:04 -0400
    • Engine revision b13c765675
    • Dart version 2.15.0 (build 2.15.0-24.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.59.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.25.0

[✓] Connected device (3 available)
    • M2007J20CG (mobile)    • 5dd3be00                  • android-arm64  •
      Android 11 (API 30)
    • Nexus’ IPhone (mobile) • 00008020-001875E83A38002E • ios            • iOS
      14.6 18F72
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 92.0.4515.131

• No issues found!

[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.1 20G80 darwin-arm, locale
    en-GH)
    • Flutter version 2.2.3 at /Users/nexus/dev/sdks/flutter
    • Framework revision f4abaa0735 (7 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.59.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.25.0

[✓] Connected device (3 available)
    • M2007J20CG (mobile)    • 5dd3be00                  • android-arm64  •
      Android 11 (API 30)
    • Nexus’ IPhone (mobile) • 00008020-001875E83A38002E • ios            • iOS
      14.6
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 92.0.4515.131

• No issues found!

Hmm I just tried to reproduce on the latest master, now I'm seeing something different and worse. It does not even let me scroll through any of the items at all, even before tapping into an item

That is rather odd. May I know what device you were using for your testing?

Yep, I was using a Pixel 5 running Android 11. Its certainly strange behavior

Perhaps this could be a device specific issue? I attempted with a OnePlus Nord this time around, running Android 11, and it seems to work just fine.
one plus nord.mp4.zip

duplicates of https://github.com/flutter/flutter/issues/40419 and should be fixed


RFC enhanced readability of testinfra fixtures

This is a proposal of a future syntax to replace current fixture system:
# capitalized fixture name that must be repeated for each test declaration
def test_something(Command, Service, Sudo, File, Package):
    [...]

Proposition 1: Just one fixture to access all modules and remove capitalization of first letter (could be named Server or Testinfra or Connection or Backend)
def test_something(Server):
    assert Server.service("nginx").is_running
    assert Server.package("nginx").version = "1.4.3"

Proposition 2: Import
import pytest
from testinfra.modules import Service

# on whole module or for each testinfra test
pytestmark = pytest.mark.testinfra

def test_something():
    assert Service("nginx").is_running

Migration path: DeprecationWarning for v1, drop old usage in v2

I really like the proposition 1, having one only entry point could low the entry barrier for testinfra (only one thing to remember) and I think it's better for auto-complete tools to show what are all the available possibilities.
But, the name Server could be misleading because you also could test containers, I would use something more meaningful and explicit to name that 'superfixture', like: testinfra_subject, or testinfra_sut (sut == subject under test), or something like that, perhaps more succinct.
Also the capitalization breaks PEP8, its a nuisance that the linter is always yelling about that function arguments must be lowercase, and also punch the principle of least astonishment:

In the current assert case assert Service("nginx").is_running, you think that you are invoking a class, obtaining an instance for the nginx service and then assert a property of that instance, that's ok.
On the proposition 1 case: assert Server.service("nginx").is_running, what do you could think? that you are calling an staticmethod ot a classmethod of the server class? and then, what do you obtain? a Server instance or a Service instance?... that's confusing.

To increase the readability the first I would do is to drop the capitalized names of fixtures.

Another advantage of proposition 1 is that have a whole server fixture could enable to end up testing more than one server in a single file. It has to be a way to define different fixtures for different servers, but this approach goes more in line with the philosophy of pytest and fixture/test composition.

Thank you for your advice @tinproject
I prefer proposition 1 too. About the name of the fixture, what about just testinfra ? This will clash with a potential import testinfra statement but it's explicit and clear that the fixture expose testinfra features.
Agree too to keep capitalized name for module who behave like classes, but some of them behave like function or objects (sudo, sysctl, systeminfo).

What about naming it ti (short version of testinfra)
This would be equivalent to:
@pytest.fixture()
def ti(TestinfraBackend):
    return TestinfraBackend

def test_foo(ti):
    assert ti.Package(...)
    assert ti.Service(...)
    assert ti.Command.check_output(...)

Of the two I'd prefer proposition 1, and I'm strongly in favor or removing the capitalization of the fixtures. I'm not sure I see a ton of value in combining all fixtures into one "parent" fixture though. If only because I like to be explicit with the fixtures I'm using.
How would doing that effect the ability to create your own modules by extending existing ones? Would you have to always extend this "parent" testinfra fixture?

I think I'm ok to remove capitalization as it make the api confusing.
Also merging the Command module inside the backend would be nice eg: ti.check_output(...) instead of ti.command.check_output(...)

@philpep as an alternative to ti, host could be used. Essentially we are creating parameters that represent each host given to testinfra.

@andrewschoen I'll go for host. Thanks for the suggestion !


Why drop()/end() are not awaiting for Promises?

Currently, there seems to be no way to detect, that we're still doing something - asking a user for a confirmation upon DND or sending something on the backend.  In other words, upon finishing a DND, it might take time to decide upon a specific action to take when firing the business logic behind the move.
For example, granted the item type is { from?: Data, to?: Data } and drop() and end() are async functions, we could write:
drop: async (item) => {
  const ret = await confirmDialog("Are you sure to move ${item.name} to ${currentName}?");
  return ret === "yes" ? {...item,  to: currentItem} : null
}

end: async (item, monitor) => {
  const res = monitor.getDropResult()
  if (res != null) {
    await callApi(res)
  }
}

OR
drop: (item) => ({...item,  to: ...currentItem})

end: async (item, monitor) => {
  const res = monitor.getDropResult()
  const ret = await confirmDialog("Are you sure to move ${item.name} to ${currentName}?");
  if (ret === "yes") {
    return await callApi(res)
  }
}

This way, we would be informed that a dragging operation is still in progress. Both source and target components could reflect this in their styles.
I just wonder why it's not done this way. In JS you get such a beautiful async almost for free. It's also good because it doesn't block the event loop. But I'm sure you know all this. Then... why?

For those reading this and want a work around, you can pass an object with a field as the promise.
Note: I'm not an expert so I'm sure this code could be cleaner.
e.g.
object passed:
{ dropped: Promise<boolean>}

drop function:
drop: (item,monitor) => {
            return {dropped: (async () => await doSomethingAsyncAndValidate(item))()}
          },

end function:
end: (draggedItem, monitor) => {
          if(monitor.didDrop()) {
              const dropResult =  (async () => {
                  const r = monitor.getDropResult<{dropped:Promise<boolean>>()
                  if(r) {
                      const dropped = await r.dropped
                      if(dropped){
                          // do some action
                      }
                  }
              })();
          }
        },


lilypond-unstable: 2.25.8 -> 2.25.9

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for lilypond-unstable is: Music typesetting system
meta.homepage for lilypond-unstable is: http://lilypond.org/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.25.9 with grep in /nix/store/npsddfrailm6kddki2576yd1c69yfxr1-lilypond-2.25.9
found 2.25.9 in filename of file in /nix/store/npsddfrailm6kddki2576yd1c69yfxr1-lilypond-2.25.9

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
lilypond-unstable
lilypond-unstable-with-fonts

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/npsddfrailm6kddki2576yd1c69yfxr1-lilypond-2.25.9 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A lilypond-unstable https://github.com/r-ryantm/nixpkgs/archive/2b367ecd33cf77fa06b1c6cfa00cc675707c229a.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/2b367ecd33cf77fa06b1c6cfa00cc675707c229a#lilypond-unstable

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/npsddfrailm6kddki2576yd1c69yfxr1-lilypond-2.25.9
ls -la /nix/store/npsddfrailm6kddki2576yd1c69yfxr1-lilypond-2.25.9/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

lilypond-unstable
lilypond-unstable-with-fonts

Maintainer pings
cc @MarcWeber @yurrriq for testing.

That's what I was about to propose, thanks bot!


chore(devtools-extension): Delete activeTab permission

Current dependencies on/for this PR:

main

PR #2254   👈

This comment was auto-generated by Graphite.


Class overflowHidden stays active after loader disappear

In every type of loader, the body element gets a "overflowHidden" class that isn't removed after loader disappears.
You can set disableScrolling="false" or disableScrolling="true" that doens't do anything.
After that the entire page, lost the ability to scroll through it

@gbast0s Thanks for reporting this issue, I will look into asap


[Removal]:

Hotspot Name
Vast Blood Baboon
Hotspot b58 Address
112nruhDvwi7ZTkkhDdxsuXzEYvmQwzWu7TbAQPJWYVLQ4fVnz8S
Discord Handle
No response
Hotspot Manufacturer
rak
Removal Reason
Hi, guys. Here is my situation. My home is side by airport. I show the picture and map below. The view from my home can see the runway. I try my best to put evidence without too much privacy issue. Please review my case. Thanks.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


[BUG] Manifests do not support labels

It looks like we never got around to supporting labels in the OAM manifest spec for Wadm. Just like Kubernetes, the metadata section of a manifest should support arbitrary key/value pairs. See https://github.com/oam-dev/spec/blob/e0991c5d0e666333ebbfa19f3490320bf671d8c0/metadata.md for what the spec calls for.
We may want to also enforce naming requirements for both labels and annotations while we're at it.

To make the case more concrete, in order for the wasmcloud-operator to more fully interoperate with tools like Helm or ArgoCD that have defaults built-in for using labels, we really do need the ability to persist labels as part of the manifest.

Oh does this fail the validation check when you add in a label @protochron ? This is a fairly easy add. What kinds of naming requirements would you like to enforce


Setting compiler options in the file itself

Currently there is no way to set compiler options inside the file itself. One idea I have to have a compile form which can be used for this. It would be the first form in the file and just for setting compiler options valid for the whole file. For example
(compile
  (warnings-as-errors true))

It will happen earliest v1.2.

Could this also/instead be a module attribute?

My thinking is that this shouldn't really have anything to do with the module as such, and it would be for the whole file. So keep it separate outside all modules.

:+1: to the strategy you proposed then.

I've needed this in several projects. Would love to see it land!


Launchpad Pro?

?????

I need a helping hand for this, because I don't have a Launchpad Pro. :)
There are two main concerns that I am aware of:

mapping the existing layouts to Pro.
leveraging the additional pads Pro has.

The first point seems easy to implement, basically creating a new target, and creating the additional packag with the new target analogously to mk2 and the adapted button and color specification<EMAIL_ADDRESS>and testing that it indeed works.
The second point is harder and involves some design steps.

Yea i have a launchpad pro and can help. :)

If you feel comfortable with submitting a PR for the first task, here's the Programmer's Guide for Pro, where you can find the button and the colour mappings.

Yea i can try
might take me a while though.
:)

Just ping me if you are stuck with something. I am currently working on making the build a bit friendlier.

Yea ok
Should i make a pull request or just download a zip of it

?

The basic process is forking the repo, working on the code and submitting a PR. The zip is distribution, with bundled and transpiled code, you don't really want to work on that :)
If you are unfamiliar with the process here's a quick guide

Ok thanks

I can't clone into the repo
it says that i do not have the perms

this was trying to clone into the fork

?

I added support for Pro in PR #16 . Please check out the branch, and try it locally.

I tried to build the source locally but make said that it couldn't built default

This is the built error I get

you need to have a newer bash. Default bash on MacOS is way too old. See building instructions.

ok will try again later when I get home

I added experimental support in https://github.com/dszakallas/mixxx-launchpad/releases/tag/v2.2.0
Check out and open an issue if you face any problems. Thanks.


[Question] projector weights of llava1.5（pretrain model，corresponding to llama2 and clip）

sorry, i find the base llm in your tech report of llava-v1.5 is vicuna-13b, there is projector of vicuna-13b and clip 336 in your model zoo

And any plan to release the pretrain script,  instruction script of llava-v1.5?

And any plan to release to instruction training dataset of llava-v1.5? thanks!

sorry, i find the base llm in your tech report of llava-v1.5 is vicuna-13b, there is projector of vicuna-13b and clip 336 in your model zoo

Sorry I missed this issue on the data release day. I tried to find all of them but for some reason this was missed.
[10/11] The training data and scripts of LLaVA-1.5 are released here, and evaluation scripts are released here!


h:stack doesn't have size medium(m) defind

During testing I found that there is no value for medium (m) spacing on hstack

Well spotted – added now in https://github.com/almonk/pylon/commit/ef244df41cb332e5ee7d97e9738800702c5d9a7c

Medium size is also missing for list aswell i believe - https://github.com/almonk/pylon/blob/master/src/css/list.css


java.lang.NoClassDefFoundError: com/google/common/base/Objects

Hi!
When I try to make a coverage test y receive the following error:
WARN: ----------------------------------------------------------------
WARN: Sonargraph Integration: Skipping projectXXXXXXXXXX [XXXXXXXXXXX], since no Sonargraph rules are activated in current SonarQube quality profile [TsLint].
WARN: ----------------------------------------------------------------
INFO: Sensor Lines Sensor
INFO: Sensor Lines Sensor (done) | time=28ms
INFO: Sensor Sonar-Sonargraph-Plugin [3.5]
INFO: ----------------------------------------------------------------
INFO: Sonargraph: Skipping project [XXXX] XXXXXXXX [XXXXXXX], since no Sonargraph rules are activated in current SonarQube quality profile.
INFO: ----------------------------------------------------------------
INFO: Sensor Sonar-Sonargraph-Plugin [3.5] (done) | time=2ms
INFO: Sensor SCM Sensor
INFO: Sensor SCM Sensor (done) | time=32ms
INFO: Sensor XmlFileSensor
INFO: Sensor XmlFileSensor (done) | time=1ms
INFO: Sensor Linting sensor for TypeScript files
INFO: Sensor Linting sensor for TypeScript files (done) | time=4257ms
INFO: Sensor Combined LCOV and LOC sensor
INFO: Analysing /XXXXX/XXXXXXXXXX/lcov.info
WARN: Problem during processing LCOV report: can't save DA data for line 0 (Line with number 0 doesn't belong to file app/app.ts).
Exception in thread "main" java.lang.NoClassDefFoundError: com/google/common/base/Objects
at com.pablissimo.sonar.LCOVParserImpl$FileData.addBranch(LCOVParserImpl.java:200)
at com.pablissimo.sonar.LCOVParserImpl.parse(LCOVParserImpl.java:126)
at com.pablissimo.sonar.LCOVParserImpl.(LCOVParserImpl.java:60)
at com.pablissimo.sonar.LCOVParserImpl.create(LCOVParserImpl.java:73)
at com.pablissimo.sonar.TsCoverageSensorImpl.getParser(TsCoverageSensorImpl.java:106)
at com.pablissimo.sonar.TsCoverageSensorImpl.saveMeasureFromLCOVFile(TsCoverageSensorImpl.java:81)
at com.pablissimo.sonar.TsCoverageSensorImpl.execute(TsCoverageSensorImpl.java:141)
at com.pablissimo.sonar.CombinedCoverageSensor.execute(CombinedCoverageSensor.java:34)
at org.sonar.batch.sensor.SensorWrapper.analyse(SensorWrapper.java:57)
I fix this adding the library guava-19.0.jar to your plugin in path: META-INF/lib/ and now the plugin works (I don't know if I did it right but as I say, It works for me)

Excuse me, I forgot the jar and sonarqube version:
Sonarqube: 5.6.2
typescript-plugin: 0.93-SNAPSHOT

So v0.93 was intended to be the SonarQube 6.0 supporting branch, but it looks as though there're a couple of regressions around that guava library (check out the pull requests for one that fixes things for SQ 6.0). What's odd is that I can't recreate the issue...
What version of the sonar-runner are you using, and what OS? You should in theory be safe with v0.8 or v0.9 (Windows only, there're a couple of Linux-specific bugs in there) unless you need SQ 6.0 support, but I'll try to repro with the above extra information!

Ok, thank you.
I am running sonar-runner in OSX and Linux. The version is:
WARN: sonar-runner script is deprecated. Please use sonar-scanner instead.
INFO: Scanner configuration file: /usr/local/Cellar/sonar-runner/2.7/libexec/conf/sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarQube Scanner 2.7
INFO: Java 1.8.0_101 Oracle Corporation (64-bit)
INFO: Mac OS X 10.11.6 x86_64
I will check with developers the upgrade to Sonar 6.0
Thank you

Would try the 0.8 version of the pluin before upgrading, suspect you might get the same problem with 6.0
Sent from a mobile device - apologies for any errors as a result
-------- Original message --------
From: IGZmarcosrivera<EMAIL_ADDRESS>Date: 10/10/2016 09:23 (GMT+00:00)
To: Pablissimo/SonarTsPlugin<EMAIL_ADDRESS>Cc: Pablissimo<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [Pablissimo/SonarTsPlugin] java.lang.NoClassDefFoundError: com/google/common/base/Objects (#58)
Ok, thank you.
I am running sonar-runner in OSX and Linux. The version is:
WARN: sonar-runner script is deprecated. Please use sonar-scanner instead.
INFO: Scanner configuration file: /usr/local/Cellar/sonar-runner/2.7/libexec/conf/sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarQube Scanner 2.7
INFO: Java 1.8.0_101 Oracle Corporation (64-bit)
INFO: Mac OS X 10.11.6 x86_64
I will check with developers the upgrade to Sonar 6.0
Thank you

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/Pablissimo/SonarTsPlugin/issues/58#issuecomment-252559146, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZvgPr21SCSKr6UjfIyQFkz4WYvrMFyks5qyfX5gaJpZM4KSSXp.

With 0.8 version works fine!
But it's curious why with version 0.9 we had the path problem and with this version no...

Ok, it works but doesn't send the coverage results to sonarqube.
As I said, I'll talk with developers to upgrade sonarqube to version 6.
Thank you for all!!

So v0.8 didn't handle spaces in paths on Windows at all well, and so broke in a number of situations. v0.9 was intended to fix that, but had the unexpected side-effect of breaking most (though oddly not all) Linux usages of the plugin.
The fix for that was rolled into v0.93, which then in turn seems to have broken some combinations of SQ and the runner with this Guava thing (but confusingly not all, since I've got it working on a 5.6.1 box and a 6.0 box).
Sounds like there's a gap in my test environments where I'm not picking this stuff up!


v3.0 Roadmap

Vue-Multiselect v3 Roadmap
Reasoning for the v3 Rewrite
The current 2.x version has become pretty complicated, especially on the template side. The way it currently behaves, makes it very hard to implement any accessibility improvements. Additionally, it limits the customisation options, especially on the interaction part. Adding more slots and props is sadly not a reliable long-term solution, since it will lead to further increased complexity and thus making it even harder to maintain.
Goals for the Rewrite AKA the New Architecture
The idea behind v3 is to simplify the library by breaking it apart into smaller, self-contained components responsible for fragments of the functionality (like options list, input, container, selected options), which can be replaced with developer-provided components for more control. To accomplish this, the whole “logic” part has to be extracted into an unopinionated UI-free component. This can be done by constructing a renderless component that exposes its state and methods to child components through scoped slots.
Then, the renderless component along with the smaller components can be composed and wired together to form the component that is required be the developer.
This should make it possible for developers to have almost complete control over the component and add their own functionalities on top of it, without requiring any changes within the library itself. This should lower the amount of feature-requests and thus help reduce feature-creep.
For example, you will be able to put a searchable table inside the dropdown. Or not have a dropdown at all and make it permanently open.
Here’s the visualization of the new architecture.

If this looks complicated to you – don’t worry. To keep the same, easy-to-use/just-works experience known from the current 2.x version, the rewrite will also ship with a default composition that mimics the current feel and look as well as API interface you got used to. That means, as long as you import the component import VueMultiselect from ‘vue-multiselect, you will use the that default composition.
This brings us to the breaking changes / migration part.
Breaking Changes / Migration from v2.x
Due to shipping with a pre-existing, default composition that mimics the current look and feel of the v2, there shouldn’t be that many breaking changes when migrating to the new version. Ideally, you should be able to just bump the package version and everything should work as it did, as long as you used the most popular features.
Possible breaking changes

Advanced features that could be easily implemented on top of the new architecture, that when removed from the library core could hugely simplify its internals. (I look at you option groups)
Slight changes to props, events emitted and slots that could improve the overall developer experience and flexibility.
Changes in the UX of the component.
Changes to the internals of the library. Relying on them right now might require further changes in your code.

Roadmap
All the changes are available on the v3 branch for you to try out.

[x] Extracting the functionality into a set of smaller, presentation components and a renderless component that controls them all.
[x] Move some of the functionalities to those smaller components, if they are opinionated and specific to the default composition and would hinder the customization when using the renderless component.
[ ] Removal of the features that would hinder users from fully customizing the user experience.
[ ] Collecting a list of recurring feature requests and issues, that could be solved with the rewrite.
[ ] Tests

[x] Migrate current suite
[ ] New tests for the new use cases that are now possible

[ ] User tests and feedback.
[ ] New docs.

[x] Migrate current docs to VuePress
[ ] New guide for composing the

[ ] Accessibility improvements for the default composition (through the partial components).
[ ] Exploration of ways that would further simplify the usage, even for complex cases.

How you can help?

Take the current v3 for a spin, leave your feedback here. Would love to hear your feedback on the architecture changes and the overall direction.
What you feel works well in v2 and what does not?
Which features do you think can be dropped from the library, given those could be implemented easily by the developer on top of the new architecture?
Any help with getting the docs and tests migrated would help a lot.
Any help with building new examples using the new architecture to find the limits would be much appreciated.
If you’d like to get involved in the development of the new version – send me a message on Vue’s Official Discord or on Twitter.

For the questions part, a survey will follow shortly.

 inside MultiSelectWrapper should include type="button" otherwise it emits the event for form submition

@ztomaz Thanks! That is a great a catch (must have missed it while prototyping).

Hi Damian, I am struggling with this error when I try to run npm run dev in v3:
mark:vue-multiselect marknoonan$ npm run dev

><EMAIL_ADDRESS>dev /Users/marknoonan/Sites/open-source/vue-multiselect
> vue-cli-service serve

 INFO  Starting development server...
 98% after emitting

 ERROR  Failed to compile with 2 errors                                                                                22:29:16

This relative module was not found:

* ./src/main.js in multi (webpack)-dev-server/client?http://<IP_ADDRESS>:8087/sockjs-node (webpack)/hot/dev-server.js ./src/main.js, multi (webpack)-dev-server/client?h
ttp://localhost (webpack)/hot/dev-server.js (webpack)-dev-server/client?http://<IP_ADDRESS>:8087/sockjs-node ./src/main.js

Maybe this is not something I should expect to be able to do at this point? If you can point me in a better direction to take this for a spin I'm excited to check it out. I didn't get far on debugging the error and it's time for bed! But I tried the top solutions I could find to similar errors. Nothing seemed too make much of a difference. Maybe the solution will be obvious to you.
I'm keen to help with docs and examples for v3. I really want to learn the strengths and weaknesses of the architecture you've chosen and get comfortable with the renderless stuff. Any pointers are appreciated.

Hey @marktnoonan, sorry for the late reply. I appreciate you giving it a try! The task to run to preview the library and the docs is npm run docs:dev / yarn docs:dev.

Still waiting.
 :reduce="item => item.property"

Was required to have an extra icon in the listed or selected entry if some condition is satisfied. On clicking the icon a popup has to come for capturing some extra details.
Is this possible currently?

@abhilashtg What about scope?

@abhilashtg https://github.com/DmitrySkibitsky/laravel-vue-spa-shopping-cart/blob/f29309cb17a7dc9f07f16798bffdc6d3da1de86f/resources/assets/js/components/public/catalog/Filters.vue#L27 Here add a new button to the selected items

@DmitrySkibitsky Thanks! Let me try on it.

@abhilashtg Look in the issue there are more examples of how these slots to write.)

@DmitrySkibitsky  Sure, Thank you.

I have created a fiddle for my usecase:
https://jsfiddle.net/abhilashtg/rq3twhbg/10/
The button is displayed. Even it can be an icon. I added a Bootstrap button. But the style seems not appearing.
The close icon in each selected option is dispapeared after adding the button.  I need the button to visible conditionally.

@shentao has there been any progress on v3?

@shentao , I'm about to use your component on a very large scale project, is there any news about the V3?

@coolfarmer The work has been restarted and we were able to make some really nice progress. If everything goes well, we might be able to ship an alpha release in the next 2 weeks. 🤞

Just to confirm, the v3 development paused, right? I don't know what version should I use for a new project, or even if the recommendation would be look something else.  Any news on this would be welcome. Thanks.

Sadly yes. Feel free to use the current version as it is mostly stable. The new version was supposed to be 95% backward compatible, so once it finally ships, it shouldn’t be a big problem to update.

Since v3 is in an usable state, couldn't you published an alpha version to npm? Maybe other would be interested in supporting it and maybe it would see a brighter future.  Mostly because it seems that so much work went into it, it would be a shame to lost all the effort. It really looks like a very thought out project.

I could try doing that over the weekend. Will ping you here once it's done! :)

Also, maybe pin this issue so people can see it first ! Thanks for everything you do @shentao :hugs:

@shentao do this alpha release will contains feature for reduce value?

Is the renderless component approach still the way to go for v3?
Because i find MultiselectCore.js only in the v3 branch and NOT in the next branch. In my understanding the v3 branch is obsolete and the next branch will be the v3 release, but maybe i'm wrong!?
Why i'm asking:
We are evaluating different vue select libraries that we need to style at our own - some clarification would be cool.
Thanks.

vue 3 is now the default version of 3.  How is this progressing?

What's the progress on the v3 version of VMS? There's been an v3.0.0-alpha.2 out for quite some time now, how about finalizing the upgrading to v3 soon?

For version 3, since a rewrite is a major task, and so much with Vue has changed since this roadmap was created, we're currently focused on getting a stable version of VMS working on Vue 3 based on the current VMS v2 codebase. A discussion on the direction we are heading with VMS has been opened here: https://github.com/shentao/vue-multiselect/discussions/1589


setter methods removed in 1.5

In the 1.4 api, one could do something like
def claim = new Claim().
    setIdentifier(identifiers.collect{new IdentifierDt(...)}).
    setCondition(conditions.collect{new CodingDt(...)})

It appears the setter methods have been removed in 1.5 and the only way to do that is using addIdentifier and addCondition.
Can you bring back the setter methods that allow one to set the whole collection?
For those of us who prefer a functional style of programming, that is very helpful.
Thanks!

Hi Rahul,
Thanks for the suggestion. These have been re-added to the DSTU3 structures, and will be in the next snapshot.


So do i need Mac, Linux and windows systems?

Or can I just change the -r and everything just works?
Got a simple Discord bot that the source is available for however that is 100% hostile to anyone that wants to "run" the bot and gives zero f***s about code.
So being able to publish the three binaries ready to go from my windows box would be pretty great.
Thanks

.NET - code works with core  2.1, framework 4.6.2.
not my code and took me 2 days to figure out how to go from a bunch of files with no solution or project files or any clues about libraries to run it, as I'm not a .NET C# dev.
That dev has now released new code in a different repo as core with solution/framework so will be adding my changes to it and another dev found this, warp, so would be neat if could supply the 2 or 3 (mac) binaries as single files instead of the 200+ needed for doing the core self contained deploys and then needing to run an exact command instead of just doing ./app (.NET is so hardcore on the production side it is 100% unfriendly to users... apparently 3.0 is addressing this - i get that more code could be written to make it friendlyy to run and projects with funding and customers do this....)
so .NET core 2.1 a C# project.

This would be extremely useful for a pretty standard CI/CD with just a single build agent. Like for instance, having your one jenkins machine (linux) build the executables for your app for windows, mac and linux.


Fix to PHP_INT_MAX integer wrap

Hi there, I really like your code and included it in a personal project.
After some time, I found myself in the following scenario:
$fraction1 = new Fraction(1220948601607, 36700000); $fraction2 = new Fraction(1983415189, 36700000); $fraction1->add($fraction2)
And I got the following error:

InvalidNumeratorException: Numerator must be an integer

I found that the problem is that one of the params exceeds the PHP_INT_MAX number.
I published a fix and wanted to share it with you in case you'd like to include it in your class.

Thanks, @xstat. I really appreciate that! Would you mind adding some tests for your new code?

@tomhv I created a couple of tests for the code.
Looks like due to the way the fix is built, odd fractions are not simplified to rounded numbers.
Same happens for even PHP_INT_MAX multipliers greater than 10.
So I am checking for epsilons smaller than 0.000000000001 for equality.
It's not a perfect fix but it reasonably removes the limitation on big integers.

Thanks @xstat.


How to check if tds.Num represents a NULL value

After scanning successfully a NULL value into tds.Num, what is the public method to determine if is NULL or not? tds.Num has only String() and  Rat() methods?
tds.Num{r:big.Rat{a:big.Int{neg:false, abs:big.nat(nil)}, b:big.Int{neg:false, abs:big.nat(nil)}}, precision:0, scale:0, isNull:true}

Thanks for reporting, good catch.
I should add a NullNum type which has a Valid member, similar to NullString.
Another option would be to return a nil pointer when the num is nil.
I'll try to work on it next week.

Unfortunately SAP's go-ase driver does not handle it properly either.
FYI, github.com/denisenkom/go-mssqldb handles null decimal using sql.NullString.
github.com/cockroachdb/apd/v2 has apd.Decimal and apd.NullDecimal


Decal with MeshTexture appears broken (not visible, and also affects other decals)

Godot version
4.0.3 (.NET)
System information

Windows 11
Forward+
Nvidia GTX 3060

Issue description
I am trying to use a Decal with a MeshTexture, because in my game it would be very useful to dynamically draw decal shapes at runtime, which I could do by creating a MeshTexture with SurfaceTool etc, as far as I understand.
However, Decals with MeshTextures as their texture appears to not work. There are two problems I encounter:

The Decal with the MeshTexture itself is not visible.
Other, nearby Decals with regular Texture2D textures, can also seemingly break when the MeshTexture Decal is present. It varies when moving them around relative to each other, but in many positions, when the MeshTexture Decal is present, the regular Decal can also turn invisible or be clipped.

Take a look at the reproduction project. There should be three decals visible, but only one is.  To verify that the MeshTexture used in the decal in the sample project is a valid one, you can enable the TestingTexture instance. I generated the MeshTexture by converting a Sprite2D to this MeshInstance2D.
The documentation for MeshTexture is also generally very barebone. It is hard to understand exactly what this class does and how it's used, maybe this whole issue stems from me using it incorrectly.
Steps to reproduce

Open the reproduction project and run it.
Note that only one decal (blue circle) is visible, despite there being three decals in the tree. MeshTextureDecal and RegularTextureDecal2 should be visible too, but are not.
Disable MeshTextureDecal.
Note that RegularTextureDecal2 somehow became visible after step 3.

Minimal reproduction project
meshtexture_decal_test.zip

MeshTexture can't be used with decals. It can only be used with Canvas items or custom 2D drawing commands.
The docs for MeshTexture definitely have room for improvement
The engine should also provide an error when users try to set an invalid texture type on a Decal.

MeshTexture can't be used with decals. It can only be used with Canvas items or custom 2D drawing commands.
The docs for MeshTexture definitely have room for improvement
The engine should also provide an error when users try to set an invalid texture type on a Decal.

I see, that is unfortunate. Is there any other way of using decals with textures that you dynamically create at runtime like you can with a mesh?

Is there any other way of using decals with textures that you dynamically create at runtime like you can with a mesh?

You can generate ImageTextures at run-time with a script, but this will be slow with large image sizes.

Has this issue been resolved?

I'll probably start digging into this in the next couple of days, but if this issue has been resolved do let me know!

Hello, I want to look into this issue.
Specifically, "The engine should also provide an error when users try to set an invalid texture type on a Decal."

@Meowzszs Feel free to open a pull request for this :slightly_smiling_face:


Add Web GUI to Traffic Monitor 2.0

Done https://github.com/Comcast/traffic_control/commit/d6d51d0e1c46caea37a746746528126cfc9b31de#diff-5142f7b1701e5652338ac1b063615e6b


Format WMSID 6941

Add here your WMS ID
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[ ] All filenames are lower case (including folders, images, files, etc.)
[ ] Filenames are descriptive
[ ] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[ ] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[ ] Image references in markdown contain an alternate text

Hello, the workshop URL is https://oracle-livelabs.github.io/pts/oml4sql/workshops/freetier/index.html but the pull request is in oracle-livelabs/oml (instead of pts). Is this the correct location?

Checking the Livelabs repositories I see that my WMS ID 6941 workshop exists in two repositories.
oml
pts
I don't know what to do in this case.

Hello, the workshop URL is https://oracle-livelabs.github.io/pts/oml4sql/workshops/freetier/index.html but the pull request is in oracle-livelabs/oml (instead of pts). Is this the correct location?

Checking the Livelabs repositories I see that my WMS ID 6941 workshop exists in two repositories.
oml
pts
I don't know what to do in this case.

@oracleadrian Please sync your branch to merge the PR.

Ready, branch updated

Please see comment in conversation tab, is this the correct location?

@anooshapilli worked with Adrian to address this issue


Add link: "Do you need this service in your country?"

Now that we expand the service to the Netherlands, we see the value in providing this service to other countries, as well. The Netherlands might just be the first. If visitors from other countries visit our site, they might wonder whether their country can adopt the same service.
That's why I suggest that we put a link in the "About the service" section:
"The Coronastatus service is currently used in Norway and the Netherlands. Do you need this service in your country? Let us know, and we will help you set it up with minimal effort!"

I think someone already suggested this, but we should also make a checklist of what you have to do in order to set up a new language. Off the top of my head:

Copy config and set locale for new language
Add json file with translations
Add subfolder with images for the new language (logo and social media share images)

Maybe add to the list a twitter account? coronastatusTLD like coronastatusNL. So people will actually do the PR that we need per country.


Implement namespaces & local symbols

Namespaces are cool.
Right now type-c structure is pretty flat, but sometimes it is useful to wrap things together
namespace Game {
    type State = enum {Active, Inactive}
}

local namespace InternalAPI {
    fn getGameState(sessionId: String) -> Game.State { .. }
    fn getUserStats(userId: String) -> User.Stats { .. }
}

Namespace will group everything together and is imported as it is (cannot import subparts of namespaces)
Namespace must start with capital letters
local keyword is applicable only at the top level symbols, disallowing them from being imported by default
local symbols can still be imported by using from gamestate import local InternalAPI

I am not sure how i feel about gating types behind namespaces. But I think I will allow and maybe react to feedback.

Another issue with this feature is that Pattern matching will also need to change accordingly. It currently works by checking if the first item in the pattern starts with an uppercase which has two flaws:

We can't match against constants which, according to naming conventions needs to be fully uppercase
The pattern possibly starts with a namespace.

A moment of confusion in the previous comment. We do not match directly against variables in type-c. So the pattern matching only needs to be extended to allow for lower case character if we have a potential namespace:
let windowConfig: engine.config.window.WindowMode = engine.config.window.WindowMode.Fullscreen(engine.config.window.FullScreenMode.Exclusive)

match windowConfig {
    engine.config.window.WindowMode.Fullscreen(mode) {
        rn.assert_reachable()
    }
    engine.config.window.WindowMode.Borderless(scale) {
        rn.assert_unreachable()
    }
}

New pattern type parser is:
// parsefuncs.ts
if (lexeme.type === "identifier") {
    const char = lexeme.value[0];
    const allCaps = lexeme.value.toUpperCase() === lexeme.value;

    let nextToken = parser.peek();
    // a type with a namespace, or just a type. A type either way!
    if(nextToken.type === "."){
        parser.reject();
        return parseMatchPatternType(parser, ctx);
    }
    else {
        // reject the lookahead past the identifier
        parser.rejectOne();
        if (char == char.toUpperCase()) {
            parser.reject();
            return parseMatchPatternType(parser, ctx);
        } else {
            parser.accept();
            return new VariablePatternExpression(loc, lexeme.value);
        }
    }
}


Complete documentation overview

Complete an initial draft of the documentation overview to allow any potential contributors to have something useful to read.

Now completed.


No Name Claim & Duplicate Email Claims

I have a very simple Azure web app configured to use Azure EasyAuth and have implemented this library with success. But I am having issues accessing certain fields in the HttpContext.User.Identity object.
The claims are set as expected, but the Name field is blank despite the "X-MS-CLIENT-PRINCIPAL" header containing a name claim. Manually decoding the header reveals it includes the following two lines:
"name_typ":"http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/emailaddress"
"role_typ":"http:\/\/schemas.microsoft.com\/ws\/2008\/06\/identity\/claims\/role

Which, due to this section of code in StandardPrincipleClaimMapper.cs, results in the name claim being retype as an emailaddress claim.
else if (claimsModel.Type.Equals(KnownEasyAuthClaimAliases.Name, StringComparison.OrdinalIgnoreCase))
{
    claimType = string.IsNullOrEmpty(headerPrincipalModel.NameClaimType) ? ClaimTypes.Name : headerPrincipalModel.NameClaimType;
}

This results in the identity being created with two emailaddress claims with different values, one containing my name and one containing my actual email address. The values of RoleClaimType and NameClaimType are also never passed as the "nameType" and "roleType" parameters when constructing the ClaimsIdentity object, resulting in the blank Name field.
Is there something I have configured incorrectly or is this intended behaviour? I can't seem to find anything relating to this online.
Thanks!

Thank you reporting this.
Can you provide a bit more detail about the type of auth provider being used and the dump of the headers (with sensitive info removed).
In the meantime you can use the IClaimMapper or IHeaderDictionaryTransformer to map the claims as you wish.

The mapper just passes the claims to the ClaimsIdentity object and does not do anything special to mark any of the claims as a name or role right now.
Are you suggesting we set the following fields upon constructing the ClaimsIdentity?

ClaimsIdentity.NameClaimType : https://learn.microsoft.com/en-us/dotnet/api/system.security.claims.claimsidentity.nameclaimtype?view=net-8.0#system-security-claims-claimsidentity-nameclaimtype

ClaimsIdentity.RoleClaimType: https://learn.microsoft.com/en-us/dotnet/api/system.security.claims.claimsidentity.roleclaimtype?view=net-8.0#system-security-claims-claimsidentity-roleclaimtype

This would require some design changes to allow propagating this extra information.


Updated with master branch.  Created new Robyn file

small file cleanup

Just deleting out a remnant util folder with nothing in it


feat: (reverts #108) full ros2-ws Dockerfile with fixed SHA256 for ros:iron

Description

The last PR #108 reverted three previous commits and replaced the ros2-ws Dockerfile with a simple wrapper on a previously tagged version of the (now legacy) ros2-control image. It was merged as a hotfix because the underlying docker.io/library/ros:iron image has been rebuilt and retagged many times since our last build of ros2-control, so the most recent build of ros2-ws with the plain ros:iron tag actually included breaking changes to the rclcpp::Node API and therefore breaking downstream users like the modulo library. Using the old ros2-control image that was last built in September 11, 2023 was a temporary workaround so that we could continue refactoring downstream users to expect the new holistic ros2-ws image instead of the previous variants like ros2-control-libraries, ros2-modulo or ros2-control.
Now that the initial hotfix has had time to settle in, I would prefer to revert the revert, i.e. to go back to the intended future structure of this Dockerfile and repository. However, we still want to avoid the breaking change in the base ros:iron image (for now). This can be achieved using a specific SHA256 digest instead of the plain tag.
The repository info for official docker images (https://github.com/docker-library/repo-info) is updated with the SHA256 digest of all builds. By going back in history to the ROS tag-details file from September 02, 2023, we can identify the SHA256 digest of our desired base ros:iron image as:
ros@sha256:6df9b084cb7e918455df628126b2b647d2ad2e4b0e979fb8fbc525a610573bbb

I updated the Dockerfile and build workflow in commit 7d98f0a716dba1a58fe5fdf9819af8c7e3e36a66 to use more build args (ROS_DISTRO, BASE_IMAGE, BASE_TAG) and some conditional logic to set the specific digest for iron while using the normal tag for other distros.
As part of this followup work, in commit 4bf3b7b4708c989b05f32e3b331ec5cbe939a07c I also fixed an issue with the image metadata. The tech.aica.image.metadata base.version currently uses BASE_TAG (which is equivalent to the ROS distro, i.e. iron)). I realized that package-builder:v1 will fail to parse the metadata since it expects the base version as a semver string. We will get an error along the lines of:
ERROR: failed to solve: invalid AICA metadata "{\"type\":\"base/ws\",\"base\":{\"name\":\"docker.io/library/ros\",\"version\":\"iron\"}}" in image "@aica/foss/ros2-ws": Malformed version: iron

In my opinion the simplest and safest approach is to use the VERSION arg instead (which is set from the git tag, i.e. vX.Y.Z-foo). This way the version is parsed as valid, and we can still introspect the ROS distro from it. As far as I am aware, the exact version or formulation of LabelAICABase.Version is not critical as long as we are consistent with it, but please correct me if I am mistaken @LouisBrunner.
Finally, while adjusting the image metadata, I also added a label for devcontainer metadata (see more info at https://containers.dev/implementors/reference/#labels). This basically sets some defaults which can be interpreted by devcontainer users like VSCode (unless those properties are overwritten by .devcontainer.json file). I thought the container user ros2 and the mount path for /home/ros2/ws/src are very useful defaults to have in there. I could also leave that for a separate PR, but I didn't want to rebuild patches 1.0.1 and 1.0.2 back to back for no reason.
Review guidelines

Estimated Time of Review: 15 minutes
The first four revert commits are just plain reverts of #108 in reverse order.
Then review the next three commits in order, which fix AICA metadata, set a specific base image and tag, and add devcontainer metadata accordingly.
Checklist before merging:

[ ] Confirm that the relevant changelog(s) are up-to-date in case of any user-facing changes

Thanks for tracking down the SHA!


Error in the post notify teams channel run

We get this error in the post notify teams channel run:
(node:3227) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'login' of null
    at Object.formatCompactLayout (/home/runner/work/_actions/toko-bifrost/ms-teams-deploy-card/3.1.2/dist/post/index.js:1:236544)
    at Object.formatAndNotify (/home/runner/work/_actions/toko-bifrost/ms-teams-deploy-card/3.1.2/dist/post/index.js:1:37551)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:3227) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:3227) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

runs-on: ubuntu-18.04
    steps:
      - name: Notify Teams channel
        uses<EMAIL_ADDRESS>        if: always()
        with:
          webhook-uri: ${{ secrets.MSO_TEAMS_WEBHOOK_URI }}
          github-token: ${{ github.token }}
          environment: ${{github.event.inputs.env}}
          show-on-start: false

Bump

It seems the author is no longer available:
https://github.com/toko-bifrost/ms-teams-deploy-card/blob/288bb1d919f2a1823ecbd8cb1ff5faf9d6ac2a52/src/layouts/compact.ts#L35

@aldwyn-acn do you think you can check it out soon ? ☺

Hey @abivolmv, ah yes, I will. Apologies 🙃

Hi @abivolmv, the author.login is still in the API. See this sample.
This issue only happens when the committer hasn't set its existing Github account email address in the git config --local user.email (or --global).
See this issue: Request for commits “author”: null and “committer”: null, can’t get user login
By the way, this repo has been inactive for months now I just forked it on my personal Github acct. I will be leaving the team soon and no one is going to maintain it there. So kindly check aldwyn/ms-teams-deploy-card@master for its continued maintenance.


Needs a register.js to work with React Native

The package needs an empty register.js to work with React Native as an add on for the controls.

👍 Would love to get this into npm package

I've published v0.4.1 with an empty register.js, let me know if that solves your issue

Hi, since there was no reply I'm gonna assume your issue is resolved.
Please raise another issue if not

Hello @eliasm307 !
I can confirm the issue was resolved! Thank you for the quick response!


Error ECONNRESET LTCR Error

Hi. When trying to get data, I see an error like in the screenshot.
How can I fix this?

I will close this error, since it was so many years ago, but this just looks like your network failed while it was fetching the list of coins. There is not great support for failures or retries when fetching the coin data, so I would just just try again. If you keep finding the same problem, please open a new issue.


First version of the module system

Just began working on this, have put the syntax in place for now. Basic idea is that you reference a module with a local <name> = require <modname>, where <name> is an identifier that will be how the module is referenced inside the current module, and <modname> is a string that will tell the Titan compiler where to find the module's source file (using rules similar to Lua search paths).
You reference module members (variables and functions) with <name>.<name>, where the first name is the local name that you have given the module on require, and the second name is the name of the variable or function. Modules are not first class, and there is no nesting, as you cannot export module references, so foo.bar.baz is not a valid reference to a module member. Right now foo.bar.baz is just a syntax error, once we have records this will become syntax, but the typechecker will reject it if either foo is not a record with a field bar that is also a record that has a field baz, or foo is the local name of an imported module that has a variable bar which is a record that has a field baz. Easy-peasy. 😄

Codecov Report

Merging #40 into master will increase coverage by 0.03%.
The diff coverage is 94.73%.

@@            Coverage Diff             @@
##           master      #40      +/-   ##
==========================================
+ Coverage   81.39%   81.43%   +0.03%
==========================================
  Files          16       16
  Lines        2822     2844      +22
==========================================
+ Hits         2297     2316      +19
- Misses        525      528       +3

Impacted Files
Coverage Δ

titan-compiler/lexer.lua
97.34% <100%> (ø)
:arrow_up:

titan-compiler/parser.lua
92.66% <100%> (-0.8%)
:arrow_down:

spec/parser_spec.lua
100% <100%> (ø)
:arrow_up:

titan-compiler/ast.lua
93.15% <100%> (+0.19%)
:arrow_up:

titan-compiler/coder.lua
85.19% <60%> (-0.33%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3788989...cf3d5a6. Read the comment docs.

As we discussed earlier, I am really concerned about constructs that have identical syntax to Lua but different semantics, especially since we expect programmers to hop back and forth between the two languages.
Our control structures look and behave identically to Lua; our data types do so too when they match Lua types (and are free to behave differently when they don't match Lua types). But our module system works very differently from Lua but looks the same. I really don't want to be trigger-happy about inventing new syntax in Titan (as fun as it sounds at first, it's really hard to get it right so it's always easy to fall back to copying Lua when in doubt) but I really think that different semantics should be visually distinguishable in the source code. It will help programmers make the transition more smoothly ("this is the same, this is different"), rather than feeling like they're walking on thin ice treating it as a weird subset of Lua and guessing what works and what doesn't.

As we discussed earlier, I am really concerned about constructs that have identical syntax to Lua but different semantics, especially since we expect programmers to hop back and forth between the two languages.

What construct are you talking about here? require has basically the same behavior in the common case, if you consider that modules (and currently even functions) are not first class. You import a module with local foo_alias = require "foo", and then calls a function bar that foo.titan defines with foo_alias.bar(<args>). If foo.titan defines a module variable a you can both read and write to it with foo_alias.a. The behavior for neither of those things should be surprising for a Lua programmer. The modules that you import cannot be accessed by anyone that imports you, same as Lua when you require a module and assigns it to a local variable.
With the modules themselves I am tooking a few liberties to make them easier to write, and remove some warts that Lua has due to its imperative top-level, but with require I was making an effort to copy the semantics that Lua has. We could just as easily have a magical require "foo" without a left-hand side that would be equivalent to local foo = require "foo", but I do not think it is worth diverging from Lua for the sake of three less tokens.

What construct are you talking about here? require has basically the same behavior in the common case

Yes, I was referring to the require keyword. Indeed, it produces the same result in the common case, but it's the edge cases that I'm concerned about. It looks a lot like Lua's require, but it doesn't work like it at all (it's not a function call, etc.) -- people will see require("foo") and will assume that you can do with it all that you can do with require("foo") in Lua. And then they'll conclude it's a "stripped-down/less-powerful version" of it, when in fact it's not: it's something else entirely, which we'll be able to use to drive the compilation process, eventually manage dependencies, etc.
The module system is a place where we're deviating from Lua from day one, so I think it shouldn't pretend it is a restricted version of Lua's intentionally vague module support.
Not to mention that, since we have Lua integration, users will be able to access Lua's require function from Titan, so having two requires that behave differently will be really ugly (with Titan's using an assignment that's not really an assignment and a function call that's not really a function call).
Let's just call it import, make it an evident keyword, and make a clear distinction between the static import and the dynamic require.

The thing is, if a Lua programmer coming to Titan tries to use one of the edge cases it will not just silently do something unexpected, but fail at compile time with an (hopefully informative) error message. And in time some of these edge cases can be supported by Titan's compile-time require, also, given the constraints of it being a compile-time construct. In time it will be important for Titan to have some support for conditional compilation and conditional importing, and some form of compile-time configuration, and I think we can make this work in a way that is familiar to Lua programmers.

Not to mention that, since we have Lua integration, users will be able to access Lua's require function from Titan, so having two requires that behave differently will be really ugly (with Titan's using an assignment that's not really an assignment and a function call that's not really a function call).

Actually I made require a keyword, so the programmer will not be able to call the require function that he may have got from Lua require.

Let's just call it import, make it an evident keyword, and make a clear distinction between the static import and the dynamic require.

I worry if this is just added friction from a user coming from Lua. The behavior of require, module members and their visibility and restrictions on initialization expressions, and any other compile-time constructs that we may like to support later, in my view all of these follow logically from the fact that Titan's top-level is declarative and most of its effect is compile-time, while Lua's is imperative and its effects are runtime.
Anyway, there is plenty of time for getting feedback from users and see what works and what does not, and we are free to make breaking changes to the language anytime before 1.0, so I think we should focus on getting a usable 0.1 to users ASAP, and them seeing what kind of feedback we get.

Actually I made require a keyword, so the programmer will not be able to call the require function that he may have got from Lua require.

Unless they stick it into a table (when we have them. :) ) -- anyway, I think it would be useful to have access to Lua require from within Titan functions (when managing the scripting part of a a scriptable application). require is our analogue to dlopen, while the static import is more like #include/-l

The behavior of require, module members and their visibility and restrictions on initialization expressions, and any other compile-time constructs that we may like to support later, in my view all of these follow logically from the fact that Titan's top-level is declarative and most of its effect is compile-time, while Lua's is imperative and its effects are runtime.

Yes, they do follow, I just wanted to make the distinction more evident. My working hypothesis is that things that look-the-same-but-aren't-quite-the-same is more friction:
-- How do I require a module?
-- "local foo = require 'foo'" just like Lua.
-- Nice! Thanks!

...a while later...

-- Hey, "local ok, foo = pcall(require, 'foo')" doesn't work!
-- Well, we sort of lied, you weren't using the require function you thought you were using...
-- (╯°□°)╯︵ ┻━┻

versus
-- How do I require a module? I tried require and it doesn't work
-- Ah, in Titan you use "import 'foo'": you're importing statically
-- Oh well, thanks! ¯\_(ツ)_/¯

I think having local foo = require "foo" just work would also avoid a lot of friction though. I would also expect programmers to understand that Titan is less dynamic than Lua and that not every Lua idiom can be ported intact.
I would be OK with Titan usually having more a more restrictive version of the Lua semantics, in that valid titan programs produce the same result as Lua would, but some valid Lua programs might result in a compile or runtime error if you try to run them as Titan. This would be the Gradual Guarantee that the gradual typing folk are also fond of. With require in particular, my concern would be ensuring that Titan's require will find the same modules that Lua's require would, so that converting a Lua program to Titan by adding some type annotations doesn't break the imports. (Perhaps we might need  a Titan-friendly package.path or package loader to do this?)

With require in particular, my concern would be ensuring that Titan's require will find the same modules that Lua's require would, so that converting a Lua program to Titan by adding some type annotations doesn't break the imports. (Perhaps we might need a Titan-friendly package.path or package loader to do this?)

@hugomg is very worried about this, but I repeatedly tell him that I do not see what the issue is. 😄 If you require (or import, whatever we decide to go with) a Titan module you go through the (compile-time) search path where titanc will find your .titan file. This is a mostly compile-time thing (the runtime system might do some initialization of your module at runtime, but actually loading the .so is fully up to the dynamic linker of your OS). If you require a Lua module there is nothing titanc does at compile-time, as it is a black box, at runtime this is resolved using whatever you have in the package.loaders of the Lua interpreter that you are using. Even if we go with Typed Lua-style declaration files for Lua modules, to have better autocompletion, it still does not matter what the actual module is at runtime, because titanc cannot trust the types you put in the declaration file anyway. I do not see at any point in time titanc actually having to go and load a Lua module at compile-time, which could lead to the problem that @hugomg has in mind (the compiler sees a module, at runtime it is another).
Notice that if a Titan module uses another Titan module this does not go through Lua's module loader, the .so of the first module actually has a direct reference to the .so of the other module, and this is resolved by you operating system. The user can still get in DLL hell if he is not careful, though, but this has nothing to do with Lua.

I'm more concerned about the exceptions to this rule.

I am strongly opposed to this ever being a rule in the first place: Titan was never meant to be a subset of Lua. Given the universe of Lua programs, the vast majority of them won't ever be valid Titan programs. I remain fully skeptical of the "gradual" way of thinking. Approaching its design from this perspective of "Titan as valid Lua programs" will only result in situations like the current require with an assignment-that's-not-an-assignment, function-call-that's-not-a-function-call, etc. I'm afraid we're shoehorning one language's syntax into another language's semantics and producing confusion in the process. Look at @mascarenhas's lenghty explanation to @hugomg in the comment above about the different behaviors of Titan's require. If these differences are blurry even to the dev team, imagine to users later. My case could not have been more clearly stated.

Look at @mascarenhas's lenghty explanation to @hugomg in the comment above about the different behaviors of Titan's require. If these differences are blurry even to the dev team, imagine to users later. My case could not have been more clearly stated.

I am not fully convinced, but point taken. 😃 We can change it to import for now, and then revisit this discussion after we get feedback from users.

Look at @mascarenhas's lenghty explanation to @hugomg in the comment above about the different behaviors of Titan's require. If these differences are blurry even to the dev team, imagine to users later. My case could not have been more clearly stated.

I am not fully convinced, but point taken. 😃 We can change it to import for now, and then revisit this discussion after we get feedback from users.

I'm glad we are giving a chance to import, as I totally agree with @hishamhm on this. To my mind,
we should try avoiding this feeling that Titan looks like a gradual typing Lua-like dialect, as this might bring some confusion among users, and creating our own way for handling modules is the first thing we could do to try avoiding misunderstandings.

@mascarenhas Thanks, Fabio. I just pushed a commit to do the rename. I tried to keep the changes as small as possible, using the local bar = import "foo.bar" syntax. (I just removed suport for the parenthesized variant import("foo.bar") to make it clear it's not a function call.)

Personally I'd like it if import "foo.bar" was sugar for local bar = import "foo.bar", to discourage users from renaming modules needlessly (something that happens in Lua all too often), but I thought that would be pushing it :) (keep in mind however that function declarations do have a sugared form in Lua, though, so that wouldn't be a first in the toplevel).

I was already thinking about that feature, to be honest, with exactly the
behavior that you are suggesting. :-)
Em 1 de nov de 2017 6:30 PM, "Hisham Muhammad"<EMAIL_ADDRESS>escreveu:

Personally I'd like it if import "foo.bar" was sugar for local bar =
import "foo.bar", to discourage users from renaming modules needlessly
(something that happens in Lua all too often), but I thought that would be
pushing it :) (keep in mind however that function declarations do have a
sugared form in Lua, though, so that wouldn't be a first in the toplevel).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/titan-lang/titan-v0/pull/40#issuecomment-341232667,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAABawudD0fIFmuWazRinefZ2ZAUq9ngks5syNTHgaJpZM4QHuKB
.

I took the liberty of making a cleanup since this PR contained a number of unrelated commits. I pushed the unrelated ones to master and the other ones into PR #44 so we can continue from there!


Add support for annotations

This changes the API for Typedefs since they are now of type *Typedef rather than *Type. But to make migration easier, it embeds *Type.
@samuel

Looks great. Thanks!