Move to fieldalignment linter from deprecated maligned linter

What would you like to be added:
Move from the deprecated maligned linter to the new fieldalignment linter.
Why is this needed:
Upgrading to golangci-lint 1.39.0 in https://github.com/submariner-io/shipyard/pull/519:

Deprecated linters:

maligned, replaced by fieldalignment

This is also reported as a warning in Go linting:

The linter 'maligned' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.  Replaced by govet 'fieldalignment'."

The switch itself is implemented in #1306, however it shows that fieldalignment flags more issues than maligned: it checks struct size, and “pointer size”, i.e. how much of the struct needs to be scanned for GC. This is really a minor optimisation (see https://github.com/golang/go/issues/44877 for details) but it can’t be disabled.
Further, golangci-lint can use maligned’s suggestions, at least to present them to the user; fieldalignment is also capable of producing suggestions, but golangci-lint can’t use them yet (see https://github.com/golangci/golangci-lint/issues/1779). Until that happens, switching to fieldalignment seems counter-productive to me: it is liable to find issues in structs without being able to explain how to fix them, and it does find lots of issues related to pointer coverage which are hard to fix.

Okay, thanks for digging in and summarizing so clearly @skitt.
Can we add golangci-lint ignores to for this linter matching text "pointer size" (or similar) to turn fieldalignment more into a drop-in replacment for maligned?

Further, golangci-lint can use maligned’s suggestions, at least to present them to the user; fieldalignment is also capable of producing suggestions, but golangci-lint can’t use them yet

I don't see either fieldalignment or maligned mentioned in the supported linters there, but I do think I remember maligned's suggestions.

Can we add golangci-lint ignores for this linter matching text "pointer size" (or similar) to turn fieldalignment more into a drop-in replacement for maligned?

Ah yes, I’d forgotten we could do that! I’ve added the relevant configuration in the updated PR. If it passes everything here I’ll mark it as ready for review.


Allow using include_str! in typescript_custom_section consts

As it says in the title. This would be useful for separating type definitions from the code, and you would be able to get syntax highlighting for the typescript in your editor as well.

Thanks for this! I fear this is a bit heavyweight though reimplementing the macro here, is there a way we can get rustc to expand the macro for us?

Possibly? I think it would require typescript custom sections to be specially compiled with the program and actually referenced from whatever code the CLI then calls. Idk, I'm not too familiar with the architecture of this project but I don't think there are any APIs in proc_macro that we can call to evaluate the macro.

I think this just needs to go through to a custom section though, right? Could the code for the custom section allow further compiler expansion in it?

Maybe something like a struct with a generic type T that holds a syn::Expr that can be encoded into T by using the Expr somehow? I'm not quite sure how the backend works between the macro and CLI.

Basically, the attribute macro only has access to the AST of the item, no macros are expanded at all.

Oh wow, I did not know that you could resolve merge conflicts from the GitHub website.

Er sorry so what I mean is that this isn't going to merge as-is. We don't want to get in the business of reimplementing macros. Macros can expand to other macro invocations, so if possible we may just need to tweak the expansion to allow that. Otherwise this may just be out of luck for now.

I understand that. I think what I might try to implement is a custom type that holds a syn node, and in where it implements ToTokens it just injects its node.

If that doesn't work out, I'm fine with closing this PR.

Ok I'm gonna close this for now to clear out our PR list a bit, but feel free to resubmit with results!


Windows 10 app

Where can we find a compiled Windows app?

Ok, apparently no Windows binaries yet.
You should remove

As of now SubGenesis runs on Windows and MacOS.
Download the latest binary for your platform from the releases page.

Regular users dont know how to, neither they want to build from source, so it's false advertising.
I didn't notice there was already an issue about that. Closing.
#1


Wrong version on github

The commit https://github.com/ashleydw/lightbox/commit/d5f74dbab06bb14a63a74be9dacd7672c4416017 (Release v3.3.0) was made after tagging the release on git(hub).

As a result you get commit https://github.com/ashleydw/lightbox/commit/54a802babab0f83733efe04cad501c72a41d638e if you download ekko-lightbox#3.3.0 via bower, which doesn't include the most recent changes from commit https://github.com/ashleydw/lightbox/commit/d5f74dbab06bb14a63a74be9dacd7672c4416017.

+1 have mentioned this before here: https://github.com/ashleydw/lightbox/issues/112

Sorry for adding another issue. I must have overlooked yours.

This is grunt bump adding two commits and tagging the first, I will release manually

How's this? https://github.com/ashleydw/lightbox/releases/tag/v3.3.2

Thanks for the quick fix,
it is working well for me


Why an extra setup action?

Sorry for spamming. I wonder whether it is necessary to have an extra setup action, which does not seem to be the default solution.  Wouldn't the latter make it easier for GitHub to cache the action? :-)

Hm, I just found another use case for using an extra setup action, if the single steps could be redistributed between the setup and the test task.
For my project, I use the turnstyle action to ensure some tests that access a global web service are not executed at the same time. So I run this action right before my turnstyle action:
name: smalltalkCI

on: [push, pull_request]

jobs:
  build:
    steps:
      - uses: actions/checkout@v2
      - uses: hpi-swa/setup-smalltalkCI@v1
        with:
          smalltalk-version: Squeak64-Trunk
      - name: Turnstyle (critical section)
        uses: softprops/turnstyle@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Run test suite
        run: smalltalkci -s ${{ matrix.smalltalk }}

However, this leads to unnecessarily long delay times after the first smalltalkci job instance has run (e.g. for the push) because the second job instance does not start to prepare the Squeak image before the first job instance has quitted. I could speed up my Actions workflow if this critical section could be reduced by breaking the smalltalk ci job down into separate jobs for setup + testing.
What do you think? Would this be far too complex? :-) Also, if we can use better caching as described in hpi-swa/smalltalkCI#471, the steps described here would become redundant.

Sorry for spamming.

All good, you're asking good questions :)

I wonder whether it is necessary to have an extra setup action, which does not seem to be the default solution.

What do you think the action should do? What smalltalkCI setup would be closer to a default solution?

Wouldn't the latter make it easier for GitHub to cache the action?

Sorry, but I don't understand why you need caching. If you think you need it for keeping your trunk images up-to-date, I'd say this is not something smalltalkCI users should care about at this point. A smalltalkCI build only needs a VM and an image, and images are relatively large in size (compare to source code for example). Imagine we have 1000 projects, each caching a 50MB trunk image... that's a 50GB cache size in total. If smalltalkCI provides a recent trunk image, we don't need all of this.

For my project, I use the turnstyle action to ensure some tests that access a global web service are not executed at the same time.

I don't completely understand your use case for turnstyle. But if you really need it, it seems necessary that you sacrifices build time for synchronization.

I could speed up my Actions workflow if this critical section could be reduced by breaking the smalltalk ci job down into separate jobs for setup + testing.

This sounds like a feature request for smalltalkCI, probably something like a --setup-only cmd line option. Could you please open a separate issue against smalltalkCI?
I hope I answered all your questions. If not, please let me know and feel free to file separate issues in the future. :)
Best,
Fabio

What do you think the action should do? What smalltalkCI setup would be closer to a default solution?

There are two ideals to how smalltalkCI could be invoked from an Actions workflow:
The one extreme might be to trigger it out of the box, in one single job, without wasting more lines than necessary in the workflow configuration file. This would make it as simple as possible to add smalltalkCI to a new workflow.
The other extreme, which I came up with in https://github.com/hpi-swa/setup-smalltalkCI/issues/9#issuecomment-705840677, would be to maximize modularity of jobs ...:

I don't completely understand your use case for turnstyle. But if you really need it, it seems necessary that you sacrifices build time for synchronization.

This is true, but unfortunately, GH appears not to support a built-in way to limit concurrent jobs. See this thread for more details:
How to limit concurrent workflow runs - GitHub Actions - GitHub Support Community
So I could at least burn a bit less build time if we had this --setup-only option:

This sounds like a feature request for smalltalkCI, probably something like a --setup-only cmd line option. Could you please open a separate issue against smalltalkCI?

See hpi-swa/smalltalkCI#479. :-)

Wouldn't the latter make it easier for GitHub to cache the action?

Sorry, but I don't understand why you need caching.

I admit I do not yet know what is happening behind the scenes on GitHub Actions to speed up builds, but I could imagine that they would provide docker images or any other kind of cacheable environment to reuse the dependencies for frequently used actions. However, this action (setup-smalltalkCI) appears to manually trigger apt-get which is another time-consuming operation ... If I compare this action to other actions I've met so far (e.g.<PHONE_NUMBER>/get-current-time or actions/create-release), they do not require an extra installation process. Either they don't have any dependencies at all, or there must happen some magic from the side of GitHub Actions. But I'm noticing my own impreciseness at this point, I just do not yet know about GH Actions. :-)
However, the other point is the caching of images, which probably should be discussed here instead: hpi-swa/smalltalkCI#471

If smalltalkCI provides a recent trunk image, we don't need all of this.

+1!


[docs] Fixes typos & formatting in GridListTile and GridListTileBar documentation

[x] I have followed (at least) the PR section of the contributing guide.

Fixes a couple of typos in GridListTile. Also, adds the missing accent-mark to close the code block in GridListTileBar.

Thanks!


Can not work well for Medical Image Segmentation with conv3d Model

Great work!
Recently, i adopt this unimatch idea in the medical image segmentation on the semi-supervised abdominal organs segmentation task. I find that it not works for small organs and tumor. Can you help me?

Hi,
The current information is limited. You need to provide your experimental details, such as the number of labeled cases, semi-supervised training logs, and the fully-supervised performance.

Thanks for your reply!
I have about 200 labeled and 800 unlabeled CTs. When trained with gt and pseudo labels the mean Organ_DSC is 0.9078, Tumor_DSC is about 0.3; while trained with unimatch, the mean Organ_DSC is 0.8842, Tumor_DSC is 0.0910 which is really bad.
The major difference i make in the code is that i use the gradient accumulation instead of a large batch_size because of the GPU Memory limit. And i didn't use the mixmatch in augmentation. Did you test unimatch on 3d model for medical image?

I have not explored our UniMatch for 3D medical images. But you may try different confidence thresholds and different strong augmentations (e.g., remove the color transformations, and add CutMix).

Thanks!

I have not explored our UniMatch for 3D medical images. But you may try different confidence thresholds and different strong augmentations (e.g., remove the color transformations, and add CutMix).

Thanks a lot for your kindly reply! I add cut-mix and retrain the network with more epochs, now the UniMatch has slightly
lower performance as the full supervised methods! Thank you again!


feat(warning-text): Add Component

Add the warning text component no changes to the component were made.

Looks good! Only thing is that pagination screenshot with the ellipses is being a bit temperamental in Firefox for some reason. Shall we put it back and I can investigate a bit more as I've seen it do that once as well

I didn't notice that got refreshed I'll undo that change

Yeah just saw that


JS Error: Worker time out

JS error occurred when try to convert a font file.

Which browser are you using? Can you share the name of your browser and the version? Looks like your browser doesn't support WebAssembly. This app requires WebAssembly support.
https://emscripten.org/docs/getting_started/FAQ.html#what-is-no-webassembly-support-found-build-with-s-wasm-0-to-target-javascript-instead-or-no-native-wasm-support-detected

Closing as this isn't actionable without further information.


Bridge network does not work for the 1 second after starting container.

Just after starting container on bridge network, network RTT is long like 1sec for the first second.
The issue happens on bridge network, but does not happens on host network.
If I run multiple docker command within 3sec, there is no delay on the second docker command.
$ docker run  -i -t ubuntu ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=54 time=1008 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=54 time=8.91 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=54 time=8.77 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=54 time=8.62 ms
$ docker --version
Docker version 1.8.1, build d12ea79

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I remember that I had the same bug, but I can't reproduce it now. @yoshiokatsuneo feel free to create a new issue if it still there.


Fixes upgrade issues

Most of this is to support CSRF token passing. Others are small enhancements.
Fixes #34 (actually skips 1.3 :laughing: )
Fixes #79

The RStudio version within the app_rstudio/4.1 module is 2021.09.1.


fix: return 404 if extendRoutes without Component

resolve #3351

Codecov Report

Merging #3608 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #3608   +/-   ##
=======================================
  Coverage   99.19%   99.19%
=======================================
  Files          18       18
  Lines        1122     1122
  Branches      301      301
=======================================
  Hits         1113     1113
  Misses          9        9

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 e5a4149...1d26fe6. Read the comment docs.


Keep textareas in sync

Hi, I'm not able to keep two textarea text in sync. It works fine if I only type into one textarea, but as soon as I type into the opposite one, nothing works anymore. Can anyone offer assistance? thanks
package main

import (
	"github.com/gopherjs/vecty"
	"github.com/gopherjs/vecty/elem"
	"github.com/gopherjs/vecty/event"
)

func main() {
	vecty.SetTitle("Hello Demo")
	vecty.RenderBody(&PageView{
		Input: `hello world`,
	})
}

// PageView is our main page component.
type PageView struct {
	vecty.Core
	Input string
}

// Render implements the vecty.Component interface.
func (p *PageView) Render() vecty.ComponentOrHTML {
	return elem.Body(
		elem.Div(
			elem.Heading1(vecty.Text("Foo:")),
			elem.TextArea(
				vecty.Markup(
					vecty.Style("font-family", "monospace"),
					vecty.Property("rows", 5),
					vecty.Property("cols", 70),
					event.Input(func(e *vecty.Event) {
						p.Input = e.Target.Get("value").String()
						vecty.Rerender(p)
					}),
				),
				vecty.Text(p.Input), // initial textarea text.
			),
		),

		elem.Div(
			elem.Heading1(vecty.Text("Bar:")),
			elem.TextArea(
				vecty.Markup(
					vecty.Style("font-family", "monospace"),
					vecty.Property("rows", 5),
					vecty.Property("cols", 70),
					event.Input(func(e *vecty.Event) {
						p.Input = e.Target.Get("value").String()
						vecty.Rerender(p)
					}),
				),
				vecty.Text(p.Input), // initial textarea text.
			),
		),
	)
}

Same thing on chromium and firefox, so I assume it's not just a browser fluke.
Actually if you inspect element, you can even see the text updating in real time, but the page does not reflect the update.

Fixed it by switching to vecty.Property("value", p.Input)
not really sure why it works this way, but it's solved.

Apologies I won't have time to debug this for a while, but without a doubt this is due to rerendering. Usually this happens (not just in Vecty, but also e.g. in React) because on a rerender you are recreating the textarea element (which clears the value to default) OR because you are overriding the value with one that you don't want (your "initial text area value")


ark.rb chowning the app_root instead of app_dir

This issue came up where we were mounting an NFS mount and then the chef run was failing on JDK install in the ark.rb with a permission denied error.  I started looking into it and I noticed on line 175 in ark.rb that there is a chown_R Ruby call.  I turned verbosity on to see what is going on with that line.
Here's our situation, we install almost all of our applications into /opt.  So, in this scenario, the JDK would be going into /opt/.  This scenario we had a read only NFS mount also going into /opt (ultimately, we told the folks to put the mount in /mnt where it belongs).  The permission denied occurred when ark.rb was trying to change ownership of the NFS mount point.
After turning on verbosity, I get this output for line 175:
chown -R root:root /opt
So, obviously ark.rb is trying to change ownership of the parent directory, not the JDK directory.  The line further exposes this:
FileUtils.chown_R new_resource.owner, app_group, app_root
Looks like the third parameter should be app_dir instead of app_root.

thank you

Closing due to inactivity.
If this is still an issue please reopen or open another issue. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help!
Thanks,
Sous-Chefs


Hydration utils tests + refactor

Codecov Report
Base: 70.37% // Head: 76.95% // Increases project coverage by +6.57% :tada:

Coverage data is based on head (e4b0267) compared to base (7c608dd).
Patch coverage: 80.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
+ Coverage   70.37%   76.95%   +6.57%
==========================================
  Files          24       25       +1
  Lines         503      512       +9
  Branches       94       94
==========================================
+ Hits          354      394      +40
+ Misses        139      111      -28
+ Partials       10        7       -3

Impacted Files
Coverage Δ

...c/cachingStrategies/commonCacheStrategyAbstract.ts
100.00% <ø> (ø)

src/cachingStrategies/redisStrategy.ts
40.00% <0.00%> (ø)

src/types/types.ts
100.00% <ø> (ø)

test/assets/utils/cacheKeyUtils.ts
100.00% <ø> (ø)

src/extendQuery.ts
31.81% <37.50%> (ø)

src/utils/cacheClientUtils.ts
50.87% <75.00%> (ø)

src/cachingStrategies/inMemoryStrategy.ts
55.26% <100.00%> (ø)

src/utils/cacheKeyUtils.ts
100.00% <100.00%> (ø)

src/utils/hydrationUtils.ts
97.56% <100.00%> (+70.73%)
:arrow_up:

src/utils/mongooseUtils.ts
100.00% <100.00%> (ø)

... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


need to agree to COQUI TTS license

hello developer,
thank you for this great project, i'm trying to benefit from it as a blind users loving to listen to audio books.
after runing the web ui and launching a convertion process, i get a prompt to agree to the COQUI TTS license either i have a commercial or a community license.
either typing y or n give nothing, just throw the exception that i need to agree.
for the fix, i added the following befaure the device detection line:
os.environ["COQUI_TOS_AGREED"] = "1"
thank you!

Thank you for the info!
This is actually going to be fixed once we release v.2.0
Using the same method you have described 😄 ❤


Astro blob

maybe by just removing the unused density/pressure/density_pressure methods from the 2D code will suffice?

I would rather comment them out since we will use them later in #143.


improve error messages if validating shoot/seed network disjointedness fails

What this PR does / why we need it:
If a shoot is created using the dashboard and the seed was created using the core.gardener.cloud apigroup without specifying spec.networks.shootDefaults, the shoot cannot be scheduled on that seed due to the pod/service network not being specified.
time="2019-10-30T15:02:24Z" level=info msg="Error syncing gardener-scheduler garden-core/k5iq95zyx1: found 1 possible seed cluster(s), however none have a disjoint network"

The error message shown is very misleading in that case, as the problem doesn't have anything to do with overlapping shoot/seed networks.
This PR improves the error handling and outputs more specific error messages if validating the shoot/seed network disjointedness fails:
time="2019-11-04T16:06:24+01:00" level=info msg="Error syncing gardener-scheduler garden-core/ck4hsdcguu: error(s) while validating network disjointedness: [Required value: no shoot service network specified Required value: no shoot pod network specified]"

If the shoot and seed networks actually overlap, the error message will look like this:
time="2019-11-04T16:26:06+01:00" level=info msg="Error syncing gardener-scheduler garden-core/ixubww48t5: error(s) while validating network disjointedness: [Invalid value: \"<IP_ADDRESS>/19\": shoot node network intersects with seed node network Invalid value: \"<IP_ADDRESS>/17\": shoot service network intersects with seed service network Invalid value: \"<IP_ADDRESS>/17\": shoot pod network intersects with seed pod network]"

Release note:

Improved error messages if validating the shoot/seed network disjointedness fails.

cc @rfranzke

Hm, I just noticed that I put a return statement inside the for loop which searches for seed candidates ... meaning that this solution will break stuff if multiple seeds are available but not all of them are valid candidates. Let me fix this ...

Good catch.. thanks.

@rfranzke Fixed it.


[Bug]: Trending Cryptocurrencies fails to fetch and display correct crypto details

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
When the user selects the "Trending Cryptocurrencies" option from command "/start" in the Telegram bot, the bot fails to correctly retrieve and display the cryptocurrency details. Instead of showing the correct names, symbols, and prices, the bot displays "Unknown".
Add ScreenShots

What browsers are you seeing the problem on?
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC WOB24 contributor
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

@Harish-2003
I want to fix this issue so that the results appear as follows:

Go ahead

@Harish-2003
I have made a pr for this, kindly check, and also please label my issue and pr with 'gssoc-ext' and a level as 'levelx'

Refer this issue in the pr

done


detect when point B is reached

stop the timer and play a sound or a visual effect or something.

https://github.com/bucketon/OWRandomSpeedrun/pull/45


[Social Authentication / Admin Login] - Social Federated user unable to access the Administrator access

Describe the issue:
When a social federated user logs in to the console, even with JIT provisioning the user's profile is not propagated with console.
How to reproduce:

Login to IS Console as a tenant admin
Setup a google connector for the console settings login flow
Login to Console with a google user
Provide the provisioned user with administrator settings.
Login again with the user and verify the access

Actual behavior:

The user only has the internal access and not the Administrator access

Screen recording:
https://github.com/wso2/product-is/assets/106053688/c0b30d97-ee86-4930-bc80-badceb90afa9
Expected behavior:

The user should have the administrator access

Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: [e.g., IS 5.10.0, IS 5.9.0]
OS: [e.g., Windows, Linux, Mac]
Database: [e.g., MySQL, H2]
Userstore: [e.g., LDAP, JDBC]

Optional Fields
Related issues:

Suggested labels:

Related to : https://github.com/wso2/product-is/issues/18283

Th root cause for this issue is, when retrieving roles list for the federated user it is only considering the IDP role mappings, the roles that assigned to the local account are not considered. Therefore, the scopes that comes with the administrator role does not get added to fed users. Hence, as required scopes for console are missing the above issue occurs.
Issue: https://github.com/wso2/product-is/issues/18313 may be due the same root cause.

Fixed with https://github.com/wso2/carbon-identity-framework/pull/5303


reviewdogを高速化

たぶん

Before: 2:35

https://github.com/tsg-ut/slackbot/runs/2707096543

After: 1:09

https://github.com/tsg-ut/slackbot/runs/2717182055


Added support for GHC 8.6

closes #230
Added support for GHC 8.6
While at it I also bumped GHC 8.4.3 to 8.4.4 and added macOS to all Travis builds
NOTE: GHC 8.4 fails on Mac for some reason I haven't gone into yet (but it also fails in the current master branch so at least this isn't a regression)

We might want to drop AppVeyor for GHC 8.4 since it's a known issue and won't be useful to get failed CI every time.

Thanks for the patch! I made some small changes to enables stock cabal builds.
I still think it's important to dump the poorly-maintained distributed-process package, so I'm open to suggestions for replacement.


Adding Strict Parsing Mode and Feature to Show Leftover Bytes

Strict Mode

Raises an AssertionError if an unknown wire_type is encountered or if there are remaining bytes after parsing.

Show Leftover Bytes

When not in Strict Mode, if there are any bytes left after parsing, these are returned along with the parsed data.

#13


Adding details on constructor injection behavior

Fixes #2068

Hi @ardalis, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;


For convenience, the derives-from and derives-from-open-generic specs should handle collections of source types

Currently these specifications handle only a single type. They should be able to handle a collection of input types.
This means that they would become "derives from any" (true if any of the given types are in its parent types).
A second version of each should be created which is "derives from all" which requires all of the bar types to be in the inheritance hierarchy.

Wontfix - no need for this, we can just use join together multiple specs.


kickthemout is not open

ERROR: Requirements have not been satisfied properly. Please look at the README file for configuration instructions.

use
sudo python kickthemout.py
when starting script

use
sudo python kickthemout.py
when starting script

Tried this and still had the same response.

ERROR: Requirements have not been satisfied properly. Please look at the README file for configuration instructions.

Sorry. It's my mistake. Use
sudo python3 kickthemout.py

Now it says "No module named scapy"

Ho. It's better. U use Kali?

Can you run this command?
sudo -H pip3 install -r requirements.txt


Update ReGrowthCore

Sync the 'Make Camp' gizmo

MP.RegisterSyncMethod(type, "MakeCamp");

MpCompat.RegisterLambdaDelegate(type, "Postfix", 0);

Both sync the same thing. No point syncing the same thing twice. Just stick to the method itself.

Got it! will do.

As to why sync the method and not the delegate:

Delegates have extra overhead (need to handle syncing the delegate itself, which MP handles automatically - but still needs to do it)
If a different gizmo ends up calling MakeCamp, you don't need to sync that one (although in rare cases this may be undesirable and sync each one separately)

Thanks for the explanation! I've updated the PR accordingly.


Stop retrying event tracker on context cancellation and timeout

Changes

Check for context completion in retry forever loops (in case anonymous func doesn't stop on context done)
Check for context completion in anonymous funcs passed into retry forever loops where we want to avoid printing an error log in such cases

Background
When we shutdown, the loops that retry forever treat context cancellation as a retryable error. Instead, these loops should exit.
We also log these as ERRORs when they should not be logged at all.
These are the relevant log lines:
message:2023-07-05T23:40:04.443Z [ERROR] polygon.server.polybft.state-sync-manager.event_tracker: failed to sync: error="context canceled"

and
message:2023-07-05T23:39:49.465Z [ERROR] polygon.server.polybft.state-sync-manager.event_tracker: failed to start blocktracker: error="context canceled"

Local Tests
Running with fix, shutdown looks like:
[SIGNAL] Caught signal: terminated
Gracefully shutting down client...
...

Without fix (v1.0.1):
[SIGNAL] Caught signal: terminated
Gracefully shutting down client...
...
2023-07-06T21:34:05.747+1200 [ERROR] polygon.server.polybft.state-sync-manager.event_tracker: failed to start blocktracker: error="context canceled"
2023-07-06T21:34:05.747+1200 [ERROR] polygon.server.polybft.state-sync-manager.event_tracker: failed to sync: error="context canceled"

@Stefan-Ethernal could you please review? Fix is not critical but the false ERROR log is a bit annoying for ops. Thanks

I have approved the pr. However, I have also found that currently we have a bug if tt.Sync fails, next time there will be panic because of closing of already closed channel. Please add  line (tt.ReadyCh = make(chan struct{})) in code before merge
// Sync concurrently, retrying indefinitely
go common.RetryForever(ctx, time.Second, func(ctx context.Context) error {
        tt.ReadyCh = make(chan struct{}) // re-initialize channel

        if err := tt.Sync(ctx); err != nil {
             if common.IsContextDone(err) {


feat: Add tagged notifications

Supersedes #40 by adding tags to the event. Similarly to #40, this PR:

Adds a T parameter to Event and EventListener that is () by default.
Breaking: Makes it so wait() and friends return T or Option<T> instead of () and bool.
Makes it so polling EventListener as a future returns T instead of ().

Unlike #40, I wanted to use a more sustainable method for notifying the event. Introducing the Notification trait. Its API looks like this:
trait Notification {
    type Tag;
    fn is_additional(&self) -> bool;
    fn count(&self) -> usize;
    fn fence(&self);
    fn next_tag(&mut self) -> T;
}

This roughly corresponds to the implicit parameters to the current event.notify_<is_additional>_<relaxed>(count) function. is_additional sets the additional property to true, and relaxed makes the fence do nothing instead of emitting a SeqCst fence. The next_tag function emits the tag that gets attached to the notification.
I wanted to give this some power, so I created the IntoNotification trait as well.
trait IntoNotification {
    type Tag;
    type Notify: Notification<Tag = Self::Tag>;
    fn into_notification(self) -> Self::Notify;

    fn additional(self) -> Additional<Self::Notify> { .. }
    fn relaxed(self) -> Relaxed<Self::Notify> { .. }
    fn tag<T: Clone>(self, tag: T) -> Tag<Self::Notify, T> { .. }
    fn tag_with<T, F: FnMut() -> T>(self, f: F) -> TagWith<Self::Notify, F> { .. }
}

impl<N: Notification> IntoNotification for N { .. }
impl IntoNotification for usize { .. }

This way, if we make notify() take an impl IntoNotification instead of usize, it still works as intended, as the implementation for usize::into_notification is non-additional and non-relaxed:
event.notify(3);

You can also use this system to add combinators (.additional(), .relaxed()), such that:
// Old code:
event.notify_additional(3);

// New code:
event.notify(3.additional());

Then, to add tags to a notification, you would do:
// Assume tag is a Vec<usize>
event.notify(3.tag(vec![1, 2, 3]));

// Alternate method
event.notify(3.tag_with(|| vec![1, 2, 3]));

Discussion questions:

Should Notification and IntoNotification be sealed? If it is, it means we can add new methods to it without worrying. If it isn't, it means that users can implement their own notification types. However, that may cause behavior we don't expect.

Blocked on taiki-e/portable-atomic#93, since portable_atomic_util::Arc doesn't implement Unpin and thus can't be projected until it does.

Should Notification and IntoNotification be sealed? If it's not, it means we can add new methods to it without worrying. If it is, it means that users can implement their own notification types. However, that may cause behavior we don't expect.

I think you've messed up the negation of "sealed" here.
Also, if we don't seal it, it might be a good idea to split up the IntoNotification trait up, so that the functions which users should be able to customize are separated from the rest (where customization wouldn't make sense).

I think you've messed up the negation of "sealed" here.
Also, if we don't seal it, it might be a good idea to split up the IntoNotification trait up, so that the functions which users should be able to customize are separated from the rest (where customization wouldn't make sense).

Thanks for the catch!
I've decided to seal it anyways, since you can do whatever you want using the combinators.

The MSRV failure looks spurious to me; running cargo +1.39 build and cargo +1.39 build --no-default-features both work on my machine.

I'm not like 100% sure about the design, but it looks ok to me now.


Fix code scanning alert - OpenTelemetry-Go Contrib vulnerable to denial of service in otelhttp due to unbound cardinality m...

Tracking issue for:

[ ] https://github.com/kubernetes-sigs/descheduler/security/code-scanning/13

/assign


Issues using GLSL array constructors (using OS X Snow Leopard)

Using:
$ ./run_macosx.command
The client comes up, but the central area is white and washed out. I can make out some detail around the edges, but that's it.

Given the condition of Snow Leopard's OpenGL stack, this is no surprise. I would strongly recommend you upgrading to Lion. But... Mind posting some more information about your system and the output of the console?

About my graphics:
Chipset Model:	ATI Radeon HD 4670
Type:	GPU
Bus:	PCIe
PCIe Lane Width:	x16
VRAM (Total):	256 MB
Vendor:	ATI (0x1002)
Device ID:	0x9488
Revision ID:	0x0000
ROM Revision:	113-B8030H-114
EFI Driver Version:	01.00.403
Console output:
$ ./run_macosx.command
Feb 18, 2012 7:36:45 AM org.terasology.game.Terasology main
INFO: Welcome to Terasology | Pre Alpha!
Sat Feb 18 07:36:45 PST 2012 INFO:Initialising sounds..
Sat Feb 18 07:36:46 PST 2012 INFO:- Sound works
Sat Feb 18 07:36:46 PST 2012 INFO:- 64 OpenAL source available
Sat Feb 18 07:36:46 PST 2012 INFO:- Sounds source generated
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager
INFO: Loading Terasology shader manager...
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager
INFO: GL_VERSION: 2.1 ATI-1.6.36
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager
INFO: SHADING_LANGUAGE VERSION: 1.20
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager
INFO: EXTENSIONS: GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_shading_language_100 GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_geometry_shader4 GL_EXT_transform_feedback GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_APPLE_aux_depth_stencil GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters GL_ARB_texture_env_crossbar GL_ARB_texture_border_clamp GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 GL_ARB_multisample GL_ARB_texture_env_combine GL_ARB_texture_compression GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture GL_ARB_shadow_ambient GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_occlusion_query GL_ARB_point_sprite GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ARB_pixel_buffer_object GL_ARB_draw_buffers GL_ARB_shader_texture_lod GL_ARB_color_buffer_float GL_ARB_half_float_vertex GL_ARB_texture_rg GL_ARB_texture_compression_rgtc GL_ARB_framebuffer_object GL_EXT_compiled_vertex_array GL_EXT_draw_buffers2 GL_EXT_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_sRGB GL_EXT_blend_equation_separate GL_EXT_texture_mirror_clamp GL_EXT_packed_depth_stencil GL_EXT_bindable_uniform GL_EXT_texture_integer GL_EXT_gpu_shader4 GL_EXT_framebuffer_sRGB GL_EXT_provoking_vertex GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_rgb_422 GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_float_pixels GL_ATI_texture_float GL_ARB_texture_float GL_ARB_half_float_pixel GL_APPLE_pixel_buffer GL_APPLE_object_purgeable GL_NV_blend_square GL_NV_fog_distance GL_NV_conditional_render GL_ATI_texture_mirror_once GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_texture_env_combine3 GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGI_color_matrix GL_EXT_texture_array GL_EXT_vertex_array_bgra GL_ARB_instanced_arrays GL_ARB_depth_buffer_float GL_EXT_packed_float GL_EXT_texture_shared_exponent
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader highp (highp_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader highp (highp_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader blur (blur_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager printLogInfo
INFO: ERROR: 0:47: 'array of 2-component vector of float' : constructor not supported for type
ERROR: 0:54: 'array of 2-component vector of float' : no matching overloaded function found
ERROR: 0:47: 'vTaps' : redefinition
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader blur (blur_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader down (down_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader down (down_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader post (post_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader post (post_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader sky (sky_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader sky (sky_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader chunk (chunk_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader chunk (chunk_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader particle (particle_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader particle (particle_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader block (block_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader block (block_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader gelatinousCube (gelatinousCube_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader gelatinousCube (gelatinousCube_frag.glsl, type = 35632)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader clouds (clouds_vert.glsl, type = 35633)
Feb 18, 2012 7:36:52 AM org.terasology.logic.manager.ShaderManager createShader
INFO: Loading shader clouds (clouds_frag.glsl, type = 35632)
Sat Feb 18 07:36:53 PST 2012 INFO:Use Java PNG Loader = true
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/shapes
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.billboard
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.cactus
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.cube
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.loweredCube
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.stair
Feb 18, 2012 7:36:53 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.torchGrounded
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.torchWall
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Loading shape: class org.terasology.data.shapes.trimmedLoweredCube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Suggested absolute save path is: /Users/rich/Downloads/Terasology/SAVED_WORLDS/BlockManifest.groovy
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Suggested absolute save path is: /Users/rich/Downloads/Terasology/SAVED_WORLDS/ImageManifest.png
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Suggested absolute save path is: /Users/rich/Downloads/Terasology/SAVED_WORLDS/ImageManifest1.png
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Suggested absolute save path is: /Users/rich/Downloads/Terasology/SAVED_WORLDS/ImageManifest2.png
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Suggested absolute save path is: /Users/rich/Downloads/Terasology/SAVED_WORLDS/ImageManifest3.png
LOADED imageIndex: [SnowSide:0, Brick:1, ChestSides:2, GoldOre:3, CoalOre:4, CopperOre:5, PortalBlock:6, RedShroom:7, GoldBar:8, BirkBark:9, RedFlower:10, TallGrass3:11, Shrub:12, ChestFront:13, IronOre:14, DiamondBar:15, DiamondOre:16, Plank:17, PineBark:18, ChestTopBottom:19, CactusBottom:20, Cactus:21, Water:22, BrownShroom:23, TallGrass2:24, Companion:25, Tnt:26, TallGrass1:27, GrassSide:28, Ice:29, MantleStone:30, GreenLeaf:31, Dirt:32, Lava:33, BookCase:34, Stone:35, Web:36, Sand:37, CobbleStone:38, Gravel:39, IronBar:40, Grass:41, OakBark:42, Torch:43, OakTrunk:44, YellowFlower:45, Snow:46, Glass:47, CactusTop:48]
LOADED blockIndex: [Air:0, Brick:1, BrickStairFRONT:2, BrickStairRIGHT:3, BrickStairBACK:4, BrickStairLEFT:5, CobbleStone:6, Companion:7, Dirt:8, Glass:9, Gravel:10, Ice:11, MantleStone:12, Plank:13, PortalBlock:14, Sand:15, Snow:16, Stone:17, TorchFRONT:18, TorchRIGHT:19, TorchBACK:20, TorchLEFT:21, TorchBOTTOM:22, BrownShroom:23, Cactus:24, Grass:25, RedFlower:26, RedShroom:27, TallGrass1:28, TallGrass2:29, TallGrass3:30, YellowFlower:31, BirkTrunk:32, OakTrunk:33, PineTrunk:34, Lava:35, Water:36, Bookcase:37, Chest:38, CoalOre:39, CopperOre:40, DiamondOre:41, GoldOre:42, IronOre:43, DarkLeaf:44, GreenLeaf:45, RedLeaf:46]
LOADED nextByte: 47
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions
Got back the following class: class org.terasology.data.blocks.definitions.Air
Loaded block config for Class class org.terasology.data.blocks.definitions.Air: [block:[version:1, translucent:true, invisible:true, bypassSelectionRay:true, penetrable:true, castsShadows:false, renderBoundingBox:false, allowBlockAttachment:false, hardness:0], name:Air]
Preparing block with name Air
Default image returns: null
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting translucent boolean to: true
Setting invisible boolean to: true
Setting penetrable boolean to: true
Setting castsShadows boolean to: false
Setting renderBoundingBox boolean to: false
Setting allowBlockAttachment boolean to: false
Setting bypassSelectionRay boolean to: true
Setting hardness to: 0
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Air
Got back the following class: class org.terasology.data.blocks.definitions.Brick
Loaded block config for Class class org.terasology.data.blocks.definitions.Brick: [block:[version:1, shape:cube], name:Brick]
Preparing block with name Brick
Default image returns: 1
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Brick
Got back the following class: class org.terasology.data.blocks.definitions.BrickStair
Loaded block config for Class class org.terasology.data.blocks.definitions.BrickStair: [block:[version:1, faces:[all:Brick], shape:[mode:HorizontalRotation, sides:Stair]], name:BrickStair]
Preparing block with name BrickStair
Default image returns: null
Setting Block BrickStair to texture Brick for all
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: Stair
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BrickStairFRONT
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BrickStairRIGHT
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BrickStairBACK
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BrickStairLEFT
Got back the following class: class org.terasology.data.blocks.definitions.CobbleStone
Loaded block config for Class class org.terasology.data.blocks.definitions.CobbleStone: [block:[version:1, shape:cube], name:CobbleStone]
Preparing block with name CobbleStone
Default image returns: 38
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block CobbleStone
Got back the following class: class org.terasology.data.blocks.definitions.Companion
Loaded block config for Class class org.terasology.data.blocks.definitions.Companion: [block:[version:1, shape:cube], name:Companion]
Preparing block with name Companion
Default image returns: 25
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Companion
Got back the following class: class org.terasology.data.blocks.definitions.Dirt
Loaded block config for Class class org.terasology.data.blocks.definitions.Dirt: [block:[version:1, shape:cube], name:Dirt]
Preparing block with name Dirt
Default image returns: 32
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Dirt
Got back the following class: class org.terasology.data.blocks.definitions.Glass
Loaded block config for Class class org.terasology.data.blocks.definitions.Glass: [block:[version:1, translucent:true, shape:cube], name:Glass]
Preparing block with name Glass
Default image returns: 47
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting translucent boolean to: true
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Glass
Got back the following class: class org.terasology.data.blocks.definitions.Gravel
Loaded block config for Class class org.terasology.data.blocks.definitions.Gravel: [block:[version:1, shape:cube], name:Gravel]
Preparing block with name Gravel
Default image returns: 39
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Gravel
Got back the following class: class org.terasology.data.blocks.definitions.Ice
Loaded block config for Class class org.terasology.data.blocks.definitions.Ice: [block:[version:1, shape:cube, translucent:true, hardness:1], name:Ice]
Preparing block with name Ice
Default image returns: 29
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting translucent boolean to: true
Setting hardness to: 1
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Ice
Got back the following class: class org.terasology.data.blocks.definitions.MantleStone
Loaded block config for Class class org.terasology.data.blocks.definitions.MantleStone: [block:[version:1, shape:cube, hardness:0], name:MantleStone]
Preparing block with name MantleStone
Default image returns: 30
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 0
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block MantleStone
Got back the following class: class org.terasology.data.blocks.definitions.Plank
Loaded block config for Class class org.terasology.data.blocks.definitions.Plank: [block:[version:1, shape:cube], name:Plank]
Preparing block with name Plank
Default image returns: 17
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Plank
Got back the following class: class org.terasology.data.blocks.definitions.PortalBlock
Loaded block config for Class class org.terasology.data.blocks.definitions.PortalBlock: [block:[version:1, shape:cube, hardness:0], name:PortalBlock]
Preparing block with name PortalBlock
Default image returns: 6
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 0
Has shape: cube
Feb 18, 2012 7:36:54 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block PortalBlock
Got back the following class: class org.terasology.data.blocks.definitions.Sand
Loaded block config for Class class org.terasology.data.blocks.definitions.Sand: [block:[version:1, shape:cube], name:Sand]
Preparing block with name Sand
Default image returns: 37
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Sand
Got back the following class: class org.terasology.data.blocks.definitions.Snow
Loaded block config for Class class org.terasology.data.blocks.definitions.Snow: [block:[version:1, shape:cube, faces:[sides:SnowSide, bottom:Dirt]], name:Snow]
Preparing block with name Snow
Default image returns: 46
Setting Block Snow to SnowSide for sides
Setting Block Snow to Dirt for bottom
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Snow
Got back the following class: class org.terasology.data.blocks.definitions.Stone
Loaded block config for Class class org.terasology.data.blocks.definitions.Stone: [block:[version:1, shape:cube, hardness:16], name:Stone]
Preparing block with name Stone
Default image returns: 35
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 16
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Stone
Got back the following class: class org.terasology.data.blocks.definitions.Torch
Loaded block config for Class class org.terasology.data.blocks.definitions.Torch: [block:[version:1, blockform:DEFAULT, translucent:true, penetrable:true, allowBlockAttachment:false, luminance:15, hardness:1, shape:[mode:AttachToSurface, sides:TorchWall, bottom:TorchGrounded]], name:Torch]
Preparing block with name Torch
Default image returns: 43
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: DEFAULT
Block has form DEFAULT, and color source DEFAULT
Setting translucent boolean to: true
Setting penetrable boolean to: true
Setting allowBlockAttachment boolean to: false
Setting luminance to: 15
Setting hardness to: 1
Has shape: TorchWall
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TorchFRONT
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TorchRIGHT
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TorchBACK
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TorchLEFT
Has shape: TorchGrounded
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TorchBOTTOM
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/plant
Got back the following class: class org.terasology.data.blocks.definitions.plant.BrownShroom
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.BrownShroom: [block:[version:1, shape:Billboard, blockform:BILLBOARD, translucent:true, penetrable:true, hardness:1], name:BrownShroom]
Preparing block with name BrownShroom
Default image returns: 23
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Block has form BILLBOARD, and color source DEFAULT
Setting translucent boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BrownShroom
Got back the following class: class org.terasology.data.blocks.definitions.plant.Cactus
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.Cactus: [block:[version:1, shape:Cactus, faces:[top:CactusTop, bottom:CactusBottom], translucent:true], name:Cactus]
Preparing block with name Cactus
Default image returns: 21
Setting Block Cactus to CactusTop for top
Setting Block Cactus to CactusBottom for bottom
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting translucent boolean to: true
Has shape: Cactus
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Cactus
Got back the following class: class org.terasology.data.blocks.definitions.plant.Grass
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.Grass: [block:[version:1, shape:Cube, allowBlockAttachment:true, faces:[sides:GrassSide, bottom:Dirt], colorsource:COLOR_LUT, plant:[growth:[factor:0.25, weight:-0.95, increment:1, max:1, evolve:[targets:[TallGrass, YellowFlower, RedFlower], weights:[85, 10, 5]]]]], name:Grass]
Preparing block with name Grass
Default image returns: 41
Setting Block Grass to GrassSide for sides
Setting Block Grass to Dirt for bottom
Faces are (L, R, T, B, F, B): null
Setting COLOR_SOURCE enum to: COLOR_LUT
Block has form DEFAULT, and color source COLOR_LUT
Setting allowBlockAttachment boolean to: true
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Grass
Got back the following class: class org.terasology.data.blocks.definitions.plant.RedFlower
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.RedFlower: [block:[version:1, shape:Billboard, blockform:BILLBOARD, colorsource:FOLIAGE_LUT, translucent:true, penetrable:true, hardness:1], name:RedFlower]
Preparing block with name RedFlower
Default image returns: 10
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form BILLBOARD, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block RedFlower
Got back the following class: class org.terasology.data.blocks.definitions.plant.RedShroom
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.RedShroom: [block:[version:1, shape:Billboard, blockform:BILLBOARD, translucent:true, penetrable:true, hardness:1], name:RedShroom]
Preparing block with name RedShroom
Default image returns: 7
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Block has form BILLBOARD, and color source DEFAULT
Setting translucent boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block RedShroom
Got back the following class: class org.terasology.data.blocks.definitions.plant.TallGrass1
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.TallGrass1: [block:[version:1, shape:Billboard, blockform:BILLBOARD, colorsource:FOLIAGE_LUT, translucent:true, penetrable:true, waving:true, hardness:1], name:TallGrass1]
Preparing block with name TallGrass1
Default image returns: 27
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form BILLBOARD, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting waving boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TallGrass1
Got back the following class: class org.terasology.data.blocks.definitions.plant.TallGrass2
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.TallGrass2: [block:[version:1, shape:Billboard, blockform:BILLBOARD, colorsource:FOLIAGE_LUT, colorOffset:[0.7, 0.7, 0.7, 1.0], translucent:true, penetrable:true, waving:true, hardness:1], name:TallGrass2]
Preparing block with name TallGrass2
Default image returns: 24
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form BILLBOARD, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting waving boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Setting colorOffset to: [0.7, 0.7, 0.7, 1.0] (after making it a Vector4f)
The Vector4f instantiated isnull
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TallGrass2
Got back the following class: class org.terasology.data.blocks.definitions.plant.TallGrass3
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.TallGrass3: [block:[version:1, shape:Billboard, blockform:BILLBOARD, colorsource:FOLIAGE_LUT, colorOffset:[0.9, 0.9, 0.9, 1.0], translucent:true, penetrable:true, waving:true, hardness:1], name:TallGrass3]
Preparing block with name TallGrass3
Default image returns: 11
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form BILLBOARD, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting waving boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Setting colorOffset to: [0.9, 0.9, 0.9, 1.0] (after making it a Vector4f)
The Vector4f instantiated isnull
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block TallGrass3
Got back the following class: class org.terasology.data.blocks.definitions.plant.YellowFlower
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.YellowFlower: [block:[version:1, shape:Billboard, blockform:BILLBOARD, colorsource:FOLIAGE_LUT, translucent:true, penetrable:true, hardness:1], name:YellowFlower]
Preparing block with name YellowFlower
Default image returns: 45
Faces are (L, R, T, B, F, B): null
Setting BLOCK_FORM enum to: BILLBOARD
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form BILLBOARD, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting penetrable boolean to: true
Setting hardness to: 1
Has shape: Billboard
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block YellowFlower
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/plant/tree
Got back the following class: class org.terasology.data.blocks.definitions.plant.tree.BirkTrunk
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.tree.BirkTrunk: [block:[version:1, shape:Cube, hardness:6, faces:[topbottom:OakTrunk, sides:BirkBark]], name:BirkTrunk]
Preparing block with name BirkTrunk
Default image returns: null
Setting Block BirkTrunk to BirkBark for sides
Setting Block BirkTrunk to OakTrunk for topbottom
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 6
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block BirkTrunk
Got back the following class: class org.terasology.data.blocks.definitions.plant.tree.OakTrunk
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.tree.OakTrunk: [block:[version:1, shape:Cube, hardness:6, faces:[sides:OakBark], plant:[growth:[factor:0.05, weight:-1, increment:50, max:50]], tree:[leaves:[block:GreenLeaf], generation:[lstuff:Goes here], wood:[block:Plank]]], name:OakTrunk]
Preparing block with name OakTrunk
Default image returns: 44
Setting Block OakTrunk to OakBark for sides
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 6
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block OakTrunk
Got back the following class: class org.terasology.data.blocks.definitions.plant.tree.PineTrunk
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.tree.PineTrunk: [block:[version:1, shape:Cube, hardness:6, faces:[topbottom:OakTrunk, sides:PineBark]], name:PineTrunk]
Preparing block with name PineTrunk
Default image returns: null
Setting Block PineTrunk to PineBark for sides
Setting Block PineTrunk to OakTrunk for topbottom
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Setting hardness to: 6
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block PineTrunk
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/liquid
Got back the following class: class org.terasology.data.blocks.definitions.liquid.Lava
Loaded block config for Class class org.terasology.data.blocks.definitions.liquid.Lava: [block:[version:1, shape:TrimmedLoweredCube, loweredShape:LoweredCube, luminance:15, hardness:0], name:Lava]
Preparing block with name Lava
Default image returns: 33
Faces are (L, R, T, B, F, B): null
Block has form LOWERED_BLOCK, and color source DEFAULT
Has lowered shape: LoweredCube
Setting luminance to: 15
Setting hardness to: 0
Has shape: TrimmedLoweredCube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Lava
Got back the following class: class org.terasology.data.blocks.definitions.liquid.Water
Loaded block config for Class class org.terasology.data.blocks.definitions.liquid.Water: [block:[version:1, shape:TrimmedLoweredCube, loweredShape:LoweredCube, hardness:0], name:Water]
Preparing block with name Water
Default image returns: 22
Faces are (L, R, T, B, F, B): null
Block has form LOWERED_BLOCK, and color source DEFAULT
Has lowered shape: LoweredCube
Setting hardness to: 0
Has shape: TrimmedLoweredCube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Water
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/furniture
Got back the following class: class org.terasology.data.blocks.definitions.furniture.Bookcase
Loaded block config for Class class org.terasology.data.blocks.definitions.furniture.Bookcase: [block:[version:1, faces:[topbottom:ChestTopBottom, left:ChestTopBottom, right:ChestTopBottom, back:ChestTopBottom], meta:class org.terasology.data.blocks.definitions.furniture.Bookcase], name:Bookcase]
Preparing block with name Bookcase
Default image returns: null
Setting Block Bookcase to ChestTopBottom for topbottom
Setting Block Bookcase to ChestTopBottom for left
Setting Block Bookcase to ChestTopBottom for right
Setting Block Bookcase to ChestTopBottom for back
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Bookcase
Got back the following class: class org.terasology.data.blocks.definitions.furniture.Chest
Loaded block config for Class class org.terasology.data.blocks.definitions.furniture.Chest: [block:[version:1, faces:[sides:ChestSides, front:ChestFront, topbottom:ChestTopBottom], meta:class org.terasology.data.blocks.definitions.furniture.Chest], name:Chest]
Preparing block with name Chest
Default image returns: null
Setting Block Chest to ChestSides for sides
Setting Block Chest to ChestTopBottom for topbottom
Setting Block Chest to ChestFront for front
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block Chest
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/mineral
Got back the following class: class org.terasology.data.blocks.definitions.mineral.CoalOre
Loaded block config for Class class org.terasology.data.blocks.definitions.mineral.CoalOre: [block:[version:1, shape:cube], name:CoalOre]
Preparing block with name CoalOre
Default image returns: 4
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block CoalOre
Got back the following class: class org.terasology.data.blocks.definitions.mineral.CopperOre
Loaded block config for Class class org.terasology.data.blocks.definitions.mineral.CopperOre: [block:[version:1, shape:cube], name:CopperOre]
Preparing block with name CopperOre
Default image returns: 5
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block CopperOre
Got back the following class: class org.terasology.data.blocks.definitions.mineral.DiamondOre
Loaded block config for Class class org.terasology.data.blocks.definitions.mineral.DiamondOre: [block:[version:1, shape:cube], name:DiamondOre]
Preparing block with name DiamondOre
Default image returns: 16
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block DiamondOre
Got back the following class: class org.terasology.data.blocks.definitions.mineral.GoldOre
Loaded block config for Class class org.terasology.data.blocks.definitions.mineral.GoldOre: [block:[version:1, shape:cube], name:GoldOre]
Preparing block with name GoldOre
Default image returns: 3
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block GoldOre
Got back the following class: class org.terasology.data.blocks.definitions.mineral.IronOre
Loaded block config for Class class org.terasology.data.blocks.definitions.mineral.IronOre: [block:[version:1, shape:cube], name:IronOre]
Preparing block with name IronOre
Default image returns: 14
Faces are (L, R, T, B, F, B): null
Block has form DEFAULT, and color source DEFAULT
Has shape: cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block IronOre
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Getting classes from org/terasology/data/blocks/definitions/plant/leaf
Got back the following class: class org.terasology.data.blocks.definitions.plant.leaf.DarkLeaf
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.leaf.DarkLeaf: [block:[version:1, shape:Cube, faces:[all:GreenLeaf], hardness:1, translucent:true, colorsource:FOLIAGE_LUT, colorOffset:[0.7, 0.7, 0.7, 1.0]], name:DarkLeaf]
Preparing block with name DarkLeaf
Default image returns: null
Setting Block DarkLeaf to texture GreenLeaf for all
Faces are (L, R, T, B, F, B): null
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form DEFAULT, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting hardness to: 1
Setting colorOffset to: [0.7, 0.7, 0.7, 1.0] (after making it a Vector4f)
The Vector4f instantiated isnull
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block DarkLeaf
Got back the following class: class org.terasology.data.blocks.definitions.plant.leaf.GreenLeaf
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.leaf.GreenLeaf: [block:[version:1, shape:Cube, translucent:true, hardness:1, colorsource:FOLIAGE_LUT], name:GreenLeaf]
Preparing block with name GreenLeaf
Default image returns: 31
Faces are (L, R, T, B, F, B): null
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form DEFAULT, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting hardness to: 1
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block GreenLeaf
Got back the following class: class org.terasology.data.blocks.definitions.plant.leaf.RedLeaf
Loaded block config for Class class org.terasology.data.blocks.definitions.plant.leaf.RedLeaf: [block:[version:1, shape:Cube, faces:[all:GreenLeaf], hardness:1, translucent:true, colorsource:FOLIAGE_LUT, colorOffset:[1.0, 0.8, 0.8, 1.0]], name:RedLeaf]
Preparing block with name RedLeaf
Default image returns: null
Setting Block RedLeaf to texture GreenLeaf for all
Faces are (L, R, T, B, F, B): null
Setting COLOR_SOURCE enum to: FOLIAGE_LUT
Block has form DEFAULT, and color source FOLIAGE_LUT
Setting translucent boolean to: true
Setting hardness to: 1
Setting colorOffset to: [1.0, 0.8, 0.8, 1.0] (after making it a Vector4f)
The Vector4f instantiated isnull
Has shape: Cube
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: Found an existing block ID value, assigning it to Block RedLeaf
Done loading blocks - _nextByte made it to 47
Final map that'll be passed to BlockManager is: [0:Block:Air;id:0, 1:Block:Brick;id:1, 2:Block:BrickStairFRONT;id:2, 3:Block:BrickStairRIGHT;id:3, 4:Block:BrickStairBACK;id:4, 5:Block:BrickStairLEFT;id:5, 6:Block:CobbleStone;id:6, 7:Block:Companion;id:7, 8:Block:Dirt;id:8, 9:Block:Glass;id:9, 10:Block:Gravel;id:10, 11:Block:Ice;id:11, 12:Block:MantleStone;id:12, 13:Block:Plank;id:13, 14:Block:PortalBlock;id:14, 15:Block:Sand;id:15, 16:Block:Snow;id:16, 17:Block:Stone;id:17, 18:Block:TorchFRONT;id:18, 19:Block:TorchRIGHT;id:19, 20:Block:TorchBACK;id:20, 21:Block:TorchLEFT;id:21, 22:Block:TorchBOTTOM;id:22, 23:PlantBlock:BrownShroom;id:23, 24:PlantBlock:Cactus;id:24, 25:PlantBlock:Grass;id:25, 26:PlantBlock:RedFlower;id:26, 27:PlantBlock:RedShroom;id:27, 28:PlantBlock:TallGrass1;id:28, 29:PlantBlock:TallGrass2;id:29, 30:PlantBlock:TallGrass3;id:30, 31:PlantBlock:YellowFlower;id:31, 32:TreeBlock:BirkTrunk;id:32, 33:TreeBlock:OakTrunk;id:33, 34:TreeBlock:PineTrunk;id:34, 35:LiquidBlock:Lava;id:35, 36:LiquidBlock:Water;id:36, 37:Block:Bookcase;id:37, 38:Block:Chest;id:38, 39:Block:CoalOre;id:39, 40:Block:CopperOre;id:40, 41:Block:DiamondOre;id:41, 42:Block:GoldOre;id:42, 43:Block:IronOre;id:43, 44:PlantBlock:DarkLeaf;id:44, 45:PlantBlock:GreenLeaf;id:45, 46:PlantBlock:RedLeaf;id:46]
Feb 18, 2012 7:36:55 AM java_util_logging_Logger$info call
INFO: _imageManifest file: /Users/rich/Downloads/Terasology/SAVED_WORLDS/ImageManifest.png
Blocks by title: {BrickStairRIGHT=Block:BrickStairRIGHT;id:3, MantleStone=Block:MantleStone;id:12, Dirt=Block:Dirt;id:8, BrickStairBACK=Block:BrickStairBACK;id:4, CoalOre=Block:CoalOre;id:39, Lava=LiquidBlock:Lava;id:35, BrickStairLEFT=Block:BrickStairLEFT;id:5, TorchFRONT=Block:TorchFRONT;id:18, Ice=Block:Ice;id:11, RedLeaf=PlantBlock:RedLeaf;id:46, Grass=PlantBlock:Grass;id:25, BrickStairFRONT=Block:BrickStairFRONT;id:2, Air=Block:Air;id:0, TorchBACK=Block:TorchBACK;id:20, Cactus=PlantBlock:Cactus;id:24, Brick=Block:Brick;id:1, Bookcase=Block:Bookcase;id:37, OakTrunk=TreeBlock:OakTrunk;id:33, RedShroom=PlantBlock:RedShroom;id:27, RedFlower=PlantBlock:RedFlower;id:26, BirkTrunk=TreeBlock:BirkTrunk;id:32, Stone=Block:Stone;id:17, Companion=Block:Companion;id:7, Chest=Block:Chest;id:38, DiamondOre=Block:DiamondOre;id:41, Water=LiquidBlock:Water;id:36, GreenLeaf=PlantBlock:GreenLeaf;id:45, GoldOre=Block:GoldOre;id:42, Sand=Block:Sand;id:15, DarkLeaf=PlantBlock:DarkLeaf;id:44, TorchBOTTOM=Block:TorchBOTTOM;id:22, CopperOre=Block:CopperOre;id:40, TallGrass1=PlantBlock:TallGrass1;id:28, IronOre=Block:IronOre;id:43, TallGrass2=PlantBlock:TallGrass2;id:29, TallGrass3=PlantBlock:TallGrass3;id:30, Gravel=Block:Gravel;id:10, BrownShroom=PlantBlock:BrownShroom;id:23, Snow=Block:Snow;id:16, YellowFlower=PlantBlock:YellowFlower;id:31, Plank=Block:Plank;id:13, Glass=Block:Glass;id:9, TorchLEFT=Block:TorchLEFT;id:21, CobbleStone=Block:CobbleStone;id:6, TorchRIGHT=Block:TorchRIGHT;id:19, PortalBlock=Block:PortalBlock;id:14, PineTrunk=TreeBlock:PineTrunk;id:34}
Blocks by id: {46=PlantBlock:RedLeaf;id:46,45=PlantBlock:GreenLeaf;id:45,44=PlantBlock:DarkLeaf;id:44,43=Block:IronOre;id:43,42=Block:GoldOre;id:42,41=Block:DiamondOre;id:41,40=Block:CopperOre;id:40,39=Block:CoalOre;id:39,38=Block:Chest;id:38,37=Block:Bookcase;id:37,36=LiquidBlock:Water;id:36,35=LiquidBlock:Lava;id:35,34=TreeBlock:PineTrunk;id:34,33=TreeBlock:OakTrunk;id:33,32=TreeBlock:BirkTrunk;id:32,31=PlantBlock:YellowFlower;id:31,30=PlantBlock:TallGrass3;id:30,29=PlantBlock:TallGrass2;id:29,28=PlantBlock:TallGrass1;id:28,27=PlantBlock:RedShroom;id:27,26=PlantBlock:RedFlower;id:26,25=PlantBlock:Grass;id:25,24=PlantBlock:Cactus;id:24,23=PlantBlock:BrownShroom;id:23,22=Block:TorchBOTTOM;id:22,21=Block:TorchLEFT;id:21,20=Block:TorchBACK;id:20,19=Block:TorchRIGHT;id:19,18=Block:TorchFRONT;id:18,17=Block:Stone;id:17,16=Block:Snow;id:16,15=Block:Sand;id:15,14=Block:PortalBlock;id:14,13=Block:Plank;id:13,12=Block:MantleStone;id:12,11=Block:Ice;id:11,10=Block:Gravel;id:10,9=Block:Glass;id:9,8=Block:Dirt;id:8,7=Block:Companion;id:7,6=Block:CobbleStone;id:6,5=Block:BrickStairLEFT;id:5,4=Block:BrickStairBACK;id:4,3=Block:BrickStairRIGHT;id:3,2=Block:BrickStairFRONT;id:2,1=Block:Brick;id:1,0=Block:Air;id:0}
Feb 18, 2012 7:36:56 AM org.terasology.game.Terasology initWorld
INFO: Creating new World with seed "Blockmania42"
Feb 18, 2012 7:36:57 AM org.terasology.rendering.world.WorldRenderer initPortal
INFO: Portal location is(-24352.0, 50.0, 20573.0)
Feb 18, 2012 7:37:01 AM org.terasology.game.Terasology startGame
INFO: Starting Terasology...
Feb 18, 2012 7:37:01 AM org.terasology.logic.manager.PortalManager spawnLocal
INFO: Spawning local slime at (-24352.0, 49.0, 20573.0)
Feb 18, 2012 7:37:01 AM org.terasology.logic.manager.PortalManager spawnWild
INFO: Spawning wild slime at (-24306.60139877214, 51.0, 20790.56860300084)

Nice! Thank you. This might be an easy fix. Give me a moment!

I've pushed an update that might be able to fix this issue – but I don't think that it is even possible while using an array constructor. This is an old bug in Snow Leopard and can be found here:
http://openradar.appspot.com/6121615
Upgrading to Lion will definitely fix this issue.

Was able to compile 1afbaeb7ad82c9c. Unfortunately this fix doesn't help - I'm still seeing the whiteout in center:
http://i.imgur.com/105BY.png
From what I can see from the edge of field of view, this looks very nice. Upgrading to Lion is not an option b/c it will break too many other things.
Running on a 2007 MacBook (GMA X3100 GPU chipset) also running Snow Leopard, I don't see the whiteout when tested with the latest release build. But movement is unplayably slow.

There are a lot of advanced graphic features that can be disabled and speed up gameplay quite a bit - if you're running from source you can find them under src\org\terasology\logic\manager\DefaultConfig.groovy

Found a workaround thanks to Cervator:
in src/org/terasology/logic/manager/DefaultConfig.groovy,
change:
config.put("Graphics.enablePostProcessingEffects", true)
to
config.put("Graphics.enablePostProcessingEffects", false)
Then recompile.
This resolves the original issue I reported with the  ATI Radeon HD 4670 system. Gameplay is speedy.

But without all the post-processing stuff it looks half as nice as it could. Will leave this ticket open as a reminder to search for another solution/workaround.

I'm closing this one because it's outdated and I'm posting a better description of problem under more controlled conditions.


Require it with an explicit version constraint allowing its       desired stability

[InvalidArgumentException]
Could not find a version of package kduma/laravel-soap-server matching your minimu
m-stability (stable). Require it with an explicit version constraint allowing its
desired stability.

At this moment there is no published version. At this moment you can import it as composer require kduma/laravel-soap-server:dev-master

At this moment there is no published version. At this moment you can import it as composer require kduma/laravel-soap-server:dev-master

Thanks man

This package is unfortunetely based on laminas-soap package, which is now in security maintainance only stage, and in current state is somewhat flicky in usage. I have a plan to redo my package based on PHP SOAP extension it the future.


Add CUDA 12 + win_64

Just testing at the moment.
This adds CUDA 12 Windows to the now vendored migrator to test building cuda-python.
Fixes #38
Closes https://github.com/conda-forge/cuda-python-feedstock/pull/55

@conda-forge-admin , please re-render

@conda-forge-admin , please re-render

I think we hit this issue (https://github.com/NVIDIA/cuda-python/issues/45) that is resolved in a later cuda-python. Perhaps for now we need to constrain pyparsing version manually? Though I haven't checked why Linux worked fine.

Was just looking at that issue when I saw the cross-link back to this PR 😄
Thanks Leo! 🙏
Just to add a few more options, maybe we could apply a patch here to fix the issue or make a patch release of 12.0.x with the fix?
@vzhurba01 what do you think?

It seems the problem was CUDA_HOME not set properly on Windows, which I fixed.
@vzhurbar01 Another question: Is it safe to build 12.0.0 with Cython 3.x? I see a lot of warnings in the log.

It's not. Please see issue: https://github.com/NVIDIA/cuda-python/issues/44
Should be fixed in CUDA-Python 12.2.0
For now we can constrain Cython

Looks like Cython 0.29 helps fix the weird aarch64 compilation failures, but doesn't support Python 3.12z

Maybe we can disable Python 3.12 builds for now?
Think this gets easier to fix once we have a more up-to-date version of CUDA-Python

Wonder if the compilation errors would be fixed by cross-compiling (instead of emulating)

Wonder if the compilation errors would be fixed by cross-compiling (instead of emulating)

I was curious about this too, but decided to focus on Windows for now. We can try this in another PR later.

@conda-forge-admin, please rerender

Thanks all! 🙏


async subscription Thread creation

currently async subscriptions create a Thread per active subscription - this is problematic for even moderately large numbers of active subscriptions - with a 64-bit vm default Thread stack size of 1MB then 10k connections leads to a minimum 10GB memory requirement before doing any actual processing

I was evaluating nats-io and ran across the same thing.
I did a quick proof of concept to change this behavior to use a single dispatch thread for async subscriptions.
https://github.com/jtdudley2/java-nats/commit/99c17ec4fe0f29ab0c4800b1f44a8d2c84de25d3

@mccraigmccraig , @jtdudley2 , Thank you for raising and evaluating this issue.  This is an issue that spans a few of our clients.  While it's been addressed elsewhere, unfortunately it has not been addressed here in the java client yet.  I've opened #114 to add this feature by the next release.

@ColinSullivan1 do you know if anyone is actively working on this issue? It would be a major improvement for large number of subscribers.

I don't think anyone is working on this at the moment. @jtdudley2's branch looks like the right way to solve this. I think we should evaluate bringing that change in.

@tylertreat , @jtdudley2 , @pims , I apologize, haven't been able to get to this yet, and see that it is becoming an issue.
We'd want to provide option to at least enable/disable this behavior, and provide associated tests.  The most congruent client with this feature would be the .NET client PR, here, although @jtdudley2's proof of concept is simpler - a great thing.
I'll remove myself from the PR as I can't commit time to a fix near term, probably a week or so, but will add myself again if no-one picks this up - I don't want to block anyone wanting to contribute.
That being said, would anyone want to contribute a fix around this proof of concept?  I'd envision a connection level property to enable/disable, the fix in @jtdudley2's branch, and then unit tests to ensure it works.

@ColinSullivan1 @tylertreat @jtdudley2 and all others that want to contribute.
I believe that the goal of the PR should be to:

If option is selected, not create a thread per subscription. In other words, the current waitForMsgs runnable should not be started when the subscription is created.
The dispatcher pool should ensure that messages from the same subscription are dispatched (message callback invoked) in the order the messages are received from the connection.
The code doing the dispatch (if different from waitForMsgs) must ensure that if the connection/subscription is closed, messages stop being delivered.

I am not sure that @jtdudley2 poc solves 2 and 3 (I see that it does not create the thread per subscription though, which is requirement 1 in the above list).

@kozlovic , I agree, thank you for enumerating these.  For all, in #114, there are references to this feature implementation in C#, which is the closest to this client in terms of architecture.

@kozlovic I think the new pull request meets all of your requirements.
In the pull request, I currently have all of the functional tests set up to use pooled delivery.  Probably a lot of them should be run in both modes.  There is one test that fails -
ITSubscriptionTest.testAsyncErrHandler() because its assumptions are wrong for pooled delivery - it reduces its max messages after a batch of messages have begun delivery and the maximum has been checked.

PR #135 should have addressed that.


_this.target.selectionStart = _this.target.selectionEnd causes IE11 to refocus the input

When clicking between inputs directly and the input value is empty, the code _this.target.selectionStart = _this.target.selectionEnd causes IE11 to refocus the previous input.
This can lead to an infinite loop of focusing if clicking between two inputs using this modules directives.
What does this code do? I guess it's to do with setting the cursor position post formatting?

Figured it out and made a pull request.


plugin installed, but homebridge not recognizing it.

I'm getting the plugin as not registered now, it is probably a stupid problem on my part, but I cannot for the life of me figure it out.
Here is the log:
Sep 05 07:48:51 raspberrypi homebridge[2989]: /usr/local/lib/node_modules/homebridge/lib/api.js:64
Sep 05 07:48:51 raspberrypi homebridge[2989]: throw new Error("The requested accessory '" + name + "' was not registered by any plugin.");
Sep 05 07:48:51 raspberrypi homebridge[2989]: ^
Sep 05 07:48:51 raspberrypi homebridge[2799]: Error: The requested accessory 'WUWeatherStationExtended' was not registered by any plugin.
Sep 05 07:48:51 raspberrypi homebridge[2799]: at API.accessory (/usr/local/lib/node_modules/homebridge/lib/api.js:64:13)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Server._loadAccessories (/usr/local/lib/node_modules/homebridge/lib/server.js:254:42)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:81:38)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:40:10)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Module._compile (module.js:571:32)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Object.Module._extensions..js (module.js:580:10)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Module.load (module.js:488:32)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at tryModuleLoad (module.js:447:12)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Function.Module._load (module.js:439:3)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at Module.runMain (module.js:605:10)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at run (bootstrap_node.js:425:7)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at startup (bootstrap_node.js:146:9)
Sep 05 07:48:51 raspberrypi homebridge[2799]: at bootstrap_node.js:540:3
Sep 05 07:48:51 raspberrypi systemd[1]: homebridge.service: main process exited, code=exited, status=1/FAILURE
Sep 05 07:48:51 raspberrypi systemd[1]: Unit homebridge.service entered failed state.
and requisite part of the config

  {
    "accessory": "WUWeatherStationExtended",
    "name": "Weather Station",
    "interval": "4",
    "key": "xxxxxxxxxxxxxxx",
    "location": "pws:KTXTYLER51",
    "forecast": "today"
  }

Im sorry, I had an error in the config part of the readme. I already published a new version with the correct readme.
Your config should look like this and must be in the platforms part. The parameters vor interval and forecast are optional, you can delete them if you want. With your current config you would get the forecast only for today.
    {         "platform": "WeatherStation",         "name": "Weather Station",         "interval": "4",         "key": "XXXXXXXXXXXXXXX",         "location": "pws:KTXTYLER51",         "forecast": "today"     }
Please tell me if its working for you now.

Finally had a chance to do the change.
Works perfectly. Cheers to an excellent update.

Thanks for your feedback.


using braces for entry_point! saves 1 byte

The 3rd edition of the blog https://github.com/phil-opp/blog_os/blob/edition-3/blog/content/edition-3/posts/02-booting/index.md looks like
bootloader_api::entry_point!(kernel_main);

Using braces like
bootloader_api::entry_point!{kernel_main}

Doesn't need the lasting semicolon so it saves 1 byte.

Using braces is less clear IMO. I don't see any reason why you would want to save a single byte in the source code.

The different bracket styles are usually used for different things: Normal parenthesis are used for function-call-like macros, curly braces are usually used when the body contains decl- or statements-like content, and brackets are used for array-like things. We should stick to those conventions: In this case, the macro body doesn't contain decl- or statement-like tokens and doesn't have anything to do with collections of any sort. Considering that changing this would only save a single byte,IMO  we should prioritize clarity.

As bjorn3 noted, the compiled binaries are not affected by brace styles, variable names, newlines, etc. For distributing the source files, you can compress them (e.g. zip them). So there is no real advantage of saving a few bytes in the source file.
Because of this, we can freely optimize the source file for readability, as Freax13 mentioned.


Namespaceify Core

Add namespace support for core.
Increase PHP requirement to 5.3+

https://github.com/Feathur/minphp/commit/d3af4d3c698bd7dc80432ec6129cf06980ae45bd

Thanks @Feathur. Unfortunately I won't be able to use the contribution for a few reasons:

Namespace integration has already begun on the 1.0 branch (see 33aaa39c14).
For 1.0 the framework is being decomposed into independent libraries, and bridged over for backwards compatibility with version 0.x.
One issue you may wish to correct in your commit, is the use of multiple root namespaces. For example, you put Model in Lib\Model. A better choice might be Minphp\Lib\Model (essentially everything in minphp should live behind Minphp\). As I said the framework is being decomposed, so Model will end up in Minphp\Mvc\Model -- part of a totally independent library.

That's perfectly fine. My partner asked that we make the offer, but we had no expectation that you'd want to use it.


Documentation is out of date regarding Ubuntu.

The documentation mentions image library issues with Ubuntu. This is no longer the case. I've installed pyautogui on both the older 18.10 LTS version and the newer 19.04 without issues. The documentation should be updated to either remove this outdated information or at least specify that it affects version older than 18.10.

It's so confusing that I tried to install on 16.04 for several hours. After switching to 18.04, problems gone.


OAK-8642: Add warn logs while indexing if string property is larger than 100KB (Indexing)_

I wasn't feeling happy about adding another generic param F to FulltextDocumentMaker. I've uploaded a patch to oak issue which seems to extract much of the logic in FulltextDocumentMaker (I also modified system param parsing). Can you see if that change looks ok to you?

Change looks good.

Change looks good.

Ok, can you please commit it then? Also, did you think about LogCustomizer change. Maybe, at least, open an improvement for that I guess.

Opened an improvement Jira (OAK-8675) for LogCustomizer


Shift+Rightclick interactions in flight are broken

Shift+Rightclick interactions are bugged if the player is flying (creative mode flight of any kind even vanilla). The simplest example is architecturecraft's roof blocks (slopes). They use shift to determine the orientation like vanilla stairs except they can be placed sideways too. With AA installed the player doesn't visually sneak while using shift in flight (which I actually really like aesthetically) however this seems to cause a desync when placing blocks that follow these placement rules. Another person has come across this issue while placing Mekanism lasers as well.
Example with architecturecraft (seems to apply to other mod/situation as well):
Placing a roof tile while flying and holding shift places it wrong.  After updating the block by placing another one next to it it snaps to the expected position.

Not sure how much of a problem it would be to fix this. It would be nice to at least have a config option to turn off the sneak changes to at least ensure compatibility.
Mods to replicate issue:
AquaAcrobatics-1.15.2.jar
!mixinbooter-7.0.jar
_MixinBootstrap-1.1.0
architecturecraft-1.12-3.108.jar

Should be fixed in 1.15.3; thanks for this investigation. This turned out to also be the cause of another issue (#117) and the cause of that would have been near-impossible to find if not for you noticing the sneak desync in the first place.


Don't discard unmapped reads in indel realignment

When doing some QC on ADAM outputs we noticed unmapped reads were dropped in indel realignment. We need to keep all reads throughout our pipeline, mapped or no.
Improvement comments on the implementation welcome, its a bit quick and dirty but at least gives us something to talk about. The idea now is to just union the unmapped reads when realignment is complete. Could sort at this point as well but decided to leave that to the client. I'm not sure indel realignment returns a sorted RDD in the first place.

Just realized I made a bit of a mess of this pull request by using an old fork. Let me know if we can salvage this one or if you'd like me to make a new fork from scratch

Coverage increased (+0.003%) to 78.937% when pulling a0cb07e45e73727f38b0247370d51e845cae6bb4 on pauldwolfe:ADAM-2018 into 8e8007eb967d24e3296c4680bafe58b279e29ccf on bigdatagenomics:master.

Coverage increased (+0.003%) to 78.937% when pulling a0cb07e45e73727f38b0247370d51e845cae6bb4 on pauldwolfe:ADAM-2018 into 8e8007eb967d24e3296c4680bafe58b279e29ccf on bigdatagenomics:master.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2792/
Test PASSed.

Thank you for the contribution, @pauldwolfe!
No where in the scaladoc does it say that unmapped reads are filtered out; we should certainly add that.
Can the select for unmapped reads and later union happen outside the call to realignIndels?  I wonder if that might be cleaner than adding another flag to the method call.

Hey @heuermh , see your point, adding more options and conditionals always increases complexity. I don't mind pulling the fix out into my code, it's pretty straightforward.
That said, you might want to consider going the other direction, and having realign indels always return the unmapped reads. Looking at the commit that introduced this behaviour, seems like an internal performance improvement with a functional side-effect rather than an intentional behaviour change. Also from a client perspective it's easier to filter the unmapped after realignment than to do the filter + union.
Just a thought, let me know what you think. Otherwise I'll go ahead and handle in my own code.

Closing as WontFix; doc fixes should be handled separately (#2022).